aboutsummaryrefslogtreecommitdiff
path: root/contrib/bloom/blinsert.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2023-08-23 17:21:31 +0300
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2023-08-23 17:21:31 +0300
commitccadf73163ca88bdaa74b8223d4dde05d17f550b (patch)
treec62a538b03de3b3e07ed2f904f142e2e4ba7b18d /contrib/bloom/blinsert.c
parentee99330a0b39c47a7ac44c6c8fdd74e3da841ba5 (diff)
downloadpostgresql-ccadf73163ca88bdaa74b8223d4dde05d17f550b.tar.gz
postgresql-ccadf73163ca88bdaa74b8223d4dde05d17f550b.zip
Use the buffer cache when initializing an unlogged index.
Some of the ambuildempty functions used smgrwrite() directly, followed by smgrimmedsync(). A few small problems with that: Firstly, one is supposed to use smgrextend() when extending a relation, not smgrwrite(). It doesn't make much difference in production builds. smgrextend() updates the relation size cache, so you miss that, but that's harmless because we never use the cached relation size of an init fork. But if you compile with CHECK_WRITE_VS_EXTEND, you get an assertion failure. Secondly, the smgrwrite() calls were performed before WAL-logging, so the page image written to disk had 0/0 as the LSN, not the LSN of the WAL record. That's also harmless in practice, but seems sloppy. Thirdly, it's better to use the buffer cache, because then you don't need to smgrimmedsync() the relation to disk, which adds latency. Bypassing the cache makes sense for bulk operations like index creation, but not when you're just initializing an empty index. Creation of unlogged tables is hardly performance bottleneck in any real world applications, but nevertheless. Backpatch to v16, but no further. These issues should be harmless in practice, so better to not rock the boat in older branches. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi
Diffstat (limited to 'contrib/bloom/blinsert.c')
-rw-r--r--contrib/bloom/blinsert.c29
1 files changed, 3 insertions, 26 deletions
diff --git a/contrib/bloom/blinsert.c b/contrib/bloom/blinsert.c
index b42b9e6c41f..b90145148d4 100644
--- a/contrib/bloom/blinsert.c
+++ b/contrib/bloom/blinsert.c
@@ -129,7 +129,7 @@ blbuild(Relation heap, Relation index, IndexInfo *indexInfo)
RelationGetRelationName(index));
/* Initialize the meta page */
- BloomInitMetapage(index);
+ BloomInitMetapage(index, MAIN_FORKNUM);
/* Initialize the bloom build state */
memset(&buildstate, 0, sizeof(buildstate));
@@ -163,31 +163,8 @@ blbuild(Relation heap, Relation index, IndexInfo *indexInfo)
void
blbuildempty(Relation index)
{
- Page metapage;
-
- /* Construct metapage. */
- metapage = (Page) palloc_aligned(BLCKSZ, PG_IO_ALIGN_SIZE, 0);
- BloomFillMetapage(index, metapage);
-
- /*
- * Write the page and log it. It might seem that an immediate sync would
- * be sufficient to guarantee that the file exists on disk, but recovery
- * itself might remove it while replaying, for example, an
- * XLOG_DBASE_CREATE* or XLOG_TBLSPC_CREATE record. Therefore, we need
- * this even when wal_level=minimal.
- */
- PageSetChecksumInplace(metapage, BLOOM_METAPAGE_BLKNO);
- smgrwrite(RelationGetSmgr(index), INIT_FORKNUM, BLOOM_METAPAGE_BLKNO,
- metapage, true);
- log_newpage(&(RelationGetSmgr(index))->smgr_rlocator.locator, INIT_FORKNUM,
- BLOOM_METAPAGE_BLKNO, metapage, true);
-
- /*
- * An immediate sync is required even if we xlog'd the page, because the
- * write did not go through shared_buffers and therefore a concurrent
- * checkpoint may have moved the redo pointer past our xlog record.
- */
- smgrimmedsync(RelationGetSmgr(index), INIT_FORKNUM);
+ /* Initialize the meta page */
+ BloomInitMetapage(index, INIT_FORKNUM);
}
/*