Add xl_btree_delete optimization.
authorPeter Geoghegan <pg@bowt.ie>
Fri, 3 Jan 2020 20:18:13 +0000 (12:18 -0800)
committerPeter Geoghegan <pg@bowt.ie>
Fri, 3 Jan 2020 20:18:13 +0000 (12:18 -0800)
commitd2e5e20e57111cca9e14f6e5a99a186d4c66a5b7
tree3eb23c2ed6433a48866dac0ecf4cad4b6b7cbfea
parent56a3921a2f5102f804bd0ff741e144a0e6f1c0b6
Add xl_btree_delete optimization.

Commit 558a9165e08 taught _bt_delitems_delete() to produce its own XID
horizon on the primary.  Standbys no longer needed to generate their own
latestRemovedXid, since they could just use the explicitly logged value
from the primary instead.  The deleted offset numbers array from the
xl_btree_delete WAL record was no longer used by the REDO routine for
anything other than deleting the items.

This enables a minor optimization:  We now treat the array as buffer
state, not generic WAL data, following _bt_delitems_vacuum()'s example.
This should be a minor win, since it allows us to avoid including the
deleted items array in cases where XLogInsert() stores the whole buffer
anyway.  The primary goal here is to make the code more maintainable,
though.  Removing inessential differences between the two functions
highlights the fundamental differences that remain.

Also change xl_btree_delete to use uint32 for the size of the array of
item offsets being deleted.  This brings xl_btree_delete closer to
xl_btree_vacuum.  Furthermore, it seems like a good idea to use an
explicit-width integer type (the field was previously an "int").

Bump XLOG_PAGE_MAGIC because xl_btree_delete changed.

Discussion: https://postgr.es/m/CAH2-Wzkz4TjmezzfAbaV1zYrh=fr0bCpzuJTvBe5iUQ3aUPsCQ@mail.gmail.com
src/backend/access/nbtree/nbtpage.c
src/backend/access/nbtree/nbtxlog.c
src/backend/access/rmgrdesc/nbtdesc.c
src/include/access/nbtree.h
src/include/access/nbtxlog.h
src/include/access/xlog_internal.h