]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Use the buffer cache when initializing an unlogged index.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Wed, 23 Aug 2023 14:21:31 +0000 (17:21 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Wed, 23 Aug 2023 14:23:18 +0000 (17:23 +0300)
commit6bc1fd4e60e9556ba5e04710049fdf42e3134f47
tree4c5e4a4ba52c33a25c57b0c6ea5adccf9f5df64f
parent5fd424c87a86dd19d6cb15a18d1662ffc7368de1
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
contrib/bloom/blinsert.c
contrib/bloom/bloom.h
contrib/bloom/blutils.c
src/backend/access/nbtree/nbtree.c
src/backend/access/spgist/spginsert.c