Re: 64-bit XIDs in deleted nbtree pages
Masahiko Sawada <sawada.mshk@gmail.com>
On Fri, Feb 19, 2021 at 3:18 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, Feb 19, 2021 at 3:12 PM Peter Geoghegan <pg@bowt.ie> wrote: > > > > On Thu, Feb 18, 2021 at 3:13 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > Agreed. Thanks for your explanation. > > > > Attached is v5, which has some of the changes I talked about. Changes > > from v4 include: > > > > * Now only updates metapage during btvacuumcleanup() in the first > > patch, which is enough to fix the existing > > IndexVacuumInfo.num_heap_tuples issue. > > > > * Restored _bt_getbuf() page-from-FSM XID check. Out of sheer paranoia. > > > > * The second patch in the series now respects work_mem when sizing the > > BTPendingRecycle array. > > > > * New enhancement to the XID GlobalVisCheckRemovableFullXid() test > > used in the second patch, to allow it to recycle even more pages. > > (Still unsure of some of the details here.) > > Thank you for updating the patch! > > > > > I would like to commit the first patch in a few days -- I refer to the > > big patch that makes deleted page XIDs 64-bit/full. Can you take a > > look at that one, Masahiko? That would be helpful. I can produce a bug > > fix for the IndexVacuumInfo.num_heap_tuples issue fairly easily, but I > > think that that should be written after the first patch is finalized > > and committed. > > I'll look at the first patch first. The 0001 patch looks good to me. In the documentation, I think we need to update the following paragraph in the description of vacuum_cleanup_index_scale_factor: If no tuples were deleted from the heap, B-tree indexes are still scanned at the VACUUM cleanup stage when at least one of the following conditions is met: the index statistics are stale, or the index contains deleted pages that can be recycled during cleanup. Index statistics are considered to be stale if the number of newly inserted tuples exceeds the vacuum_cleanup_index_scale_factor fraction of the total number of heap tuples detected by the previous statistics collection. The total number of heap tuples is stored in the index meta-page. Note that the meta-page does not include this data until VACUUM finds no dead tuples, so B-tree index scan at the cleanup stage can only be skipped if the second and subsequent VACUUM cycles detect no dead tuples. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Recycle nbtree pages deleted during same VACUUM.
- 9dd963ae2534 14.0 landed
-
VACUUM VERBOSE: Count "newly deleted" index pages.
- 237636183909 14.0 landed
-
Use full 64-bit XIDs in deleted nbtree pages.
- e5d8a9990304 14.0 landed
-
Fix nbtree cleanup-only VACUUM stats inaccuracies.
- 48e1291342dd 14.0 cited
-
Fix undercounting in VACUUM VERBOSE output.
- 73a076b03f1c 13.0 cited
-
Delete empty pages in each pass during GIST VACUUM.
- 4e514c6180fb 13.0 cited
-
Use full 64-bit XID for checking if a deleted GiST page is old enough.
- 6655a7299d83 13.0 cited
-
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 cited
-
Skip full index scan during cleanup of B-tree indexes when possible
- 857f9c36cda5 11.0 cited
-
Do index FSM vacuuming sooner.
- c79f6df75dd3 11.0 cited
-
Avoid early reuse of btree pages, causing incorrect query results.
- d3abbbebe52e 9.2.0 cited
-
Clean up API for ambulkdelete/amvacuumcleanup as per today's discussion.
- e57345975cf8 8.2.0 cited