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
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/6bc1fd4e60e9556ba5e04710049fdf42e3134f47
Modified Files
--------------
contrib/bloom/blinsert.c | 29 ++------------
contrib/bloom/bloom.h | 2 +-
contrib/bloom/blutils.c | 8 ++--
src/backend/access/nbtree/nbtree.c | 41 ++++++++++----------
src/backend/access/spgist/spginsert.c | 71 ++++++++++++++++-------------------
5 files changed, 62 insertions(+), 89 deletions(-)