database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-09 22:41:56 +03:00
Code Activity

Truncate line pointer array during heap pruning.

Browse Source 
Reclaim space from the line pointer array when heap pruning leaves
behind a contiguous group of LP_UNUSED items at the end of the array.
This happens during subsequent page defragmentation.  Certain kinds of
heap line pointer bloat are ameliorated by this new optimization.

Follow-up work to commit 3c3b8a4b26, which taught VACUUM to truncate the
line pointer array in about the same way during VACUUM's second pass
over the heap.  We now apply line pointer array truncation during both
the first and the second pass over the heap made by VACUUM.  We can also
perform line pointer array truncation during opportunistic pruning.

Matthias van de Meent, with small tweaks by me.

Author: Matthias van de Meent <boekewurm+postgres@gmail.com>
Discussion: https://postgr.es/m/CAEze2WjgaQc55Y5f5CQd3L=eS5CZcff2Obxp=O6pto8-f0hC4w@mail.gmail.com
Discussion: https://postgr.es/m/CAEze2Wg36%2B4at2eWJNcYNiW2FJmht34x3YeX54ctUSs7kKoNcA%40mail.gmail.com
This commit is contained in:
Peter Geoghegan
2022-04-07 15:42:12 -07:00
parent 9d9c02ccd1
commit 10a8d13823
3 changed files with 33 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/backend/access/heap/pruneheap.c
View File

@ -244,7 +244,9 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
* Prune and repair fragmentation in the specified page.
*
* Caller must have pin and buffer cleanup lock on the page. Note that we
* don't update the FSM information for page on caller's behalf.
* don't update the FSM information for page on caller's behalf. Caller might
* also need to account for a reduction in the length of the line pointer
* array following array truncation by us.
*
* vistest is used to distinguish whether tuples are DEAD or RECENTLY_DEAD
* (see heap_prune_satisfies_vacuum and

11
src/backend/access/heap/vacuumlazy.c
View File

@ -223,7 +223,7 @@ typedef struct LVRelState
*/
typedef struct LVPagePruneState
{
bool hastup; /* Page is truncatable? */
bool hastup; /* Page prevents rel truncation? */
bool has_lpdead_items; /* includes existing LP_DEAD items */
/*
@ -1393,7 +1393,7 @@ lazy_scan_skip(LVRelState *vacrel, Buffer *vmbuffer, BlockNumber next_block,
*
* It's necessary to consider new pages as a special case, since the rules for
* maintaining the visibility map and FSM with empty pages are a little
* different (though new pages can be truncated based on the usual rules).
* different (though new pages can be truncated away during rel truncation).
*
* Empty pages are not really a special case -- they're just heap pages that
* have no allocated tuples (including even LP_UNUSED items). You might
@ -1561,6 +1561,11 @@ lazy_scan_prune(LVRelState *vacrel,
Assert(BufferGetBlockNumber(buf) == blkno);
/*
* maxoff might be reduced following line pointer array truncation in
* heap_page_prune. That's safe for us to ignore, since the reclaimed
* space will continue to look like LP_UNUSED items below.
*/
maxoff = PageGetMaxOffsetNumber(page);
retry:
@ -1768,7 +1773,7 @@ retry:
* Check tuple left behind after pruning to see if needs to be frozen
* now.
*/
prunestate->hastup = true; /* page won't be truncatable */
prunestate->hastup = true; /* page makes rel truncation unsafe */
if (heap_prepare_freeze_tuple(tuple.t_data,
vacrel->relfrozenxid,
vacrel->relminmxid,