On Tue, Feb 15, 2022 at 10:48 AM Matthias van de Meent <boekewurm+postg...@gmail.com> wrote: > # Truncating lp_array during pruning > =========================== > > The following adversarial load grows the heap relation, but with the > patch the relation keeps its size. The point being that HOT updates > can temporarily inflate the LP array significantly, and this patch can > actively combat that issue while we're waiting for the 2nd pass of > vacuum to arrive.
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. We should definitely increase MaxHeapTuplesPerPage before too long, for a variety of reasons that I have talked about in the past. Its current value is 291 on all mainstream platforms, a value that's derived from accidental historic details -- which predate HOT. Obviously an increase in MaxHeapTuplesPerPage is likely to make the problem that the patch proposes to solve worse. I lean towards committing the patch now as work in that direction, in fact. It helps that this patch now seems relatively low risk. -- Peter Geoghegan