On Mon, Apr 4, 2022 at 7:24 PM Peter Geoghegan <p...@bowt.ie> wrote: > I am sympathetic to the idea that giving the system a more accurate > picture of how much free space is available on each heap page is an > intrinsic good. This might help us in a few different areas. For > example, the FSM cares about relatively small differences in available > free space *among* heap pages that are "in competition" in > RelationGetBufferForTuple(). Plus we have a heuristic based on > PageGetHeapFreeSpace() in heap_page_prune_opt() to consider.
Pushed a slightly revised version of this just now. Differences: * Rewrote the comments, and adjusted related comments in vacuumlazy.c. Mostly just made them shorter. * I eventually decided that it was fine to just accept the issue with maxoff in lazy_scan_prune (the pruning path used by VACUUM). There seemed to be no need to reestablish a maxoff for the page here following further reflection. I changed my mind. Setting reclaimed line pointer array space to a pattern of 0x7F bytes wasn't adding much here. Pruning either runs in VACUUM, or opportunistically. When it runs in VACUUM things are highly constrained already. Opportunistic pruning for heap_page_prune_opt() callers doesn't even require that the caller start out with a buffer lock. Pruning only goes ahead when we successfully acquire a cleanup lock -- so callers can't be relying on maxoff not changing. * Didn't keep the changes to PageTruncateLinePointerArray(). There is at least no reason to tie this question about VACUUM to how pruning behaves. I still see some small value in avoiding creating a new path that allows PageIsEmpty() pages to come into existence in a new way, which is no less true with the patch I pushed. Thanks -- Peter Geoghegan
