On Fri, Apr 8, 2022 at 9:44 AM Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Apr 8, 2022 at 4:38 AM Matthias van de Meent > <boekewurm+postg...@gmail.com> wrote: > > Yeah, I think we should definately support more line pointers on a > > heap page, but abusing MaxHeapTuplesPerPage for that is misleading: > > the current value is the physical limit for heap tuples, as we have at > > most 1 heap tuple per line pointer and thus the MaxHeapTuplesPerPage > > won't change. A macro MaxHeapLinePointersPerPage would probably be > > more useful, which could be as follows (assuming we don't want to > > allow filling a page with effectively only dead line pointers): > > That's a good point. Sounds like it might be the right approach. > > I suppose that it will depend on how much use of MaxHeapTuplesPerPage > remains once it is split in two like this.
Thinking about this some more, I wonder if it would make sense to split MaxHeapTuplesPerPage into two new constants (a true MaxHeapTuplesPerPage, plus MaxHeapLinePointersPerPage), for the reasons discussed, but also as a way of getting a *smaller* effective MaxHeapTuplesPerPage than 291 in some contexts only. There are some ways in which the current MaxHeapTuplesPerPage isn't enough, but also some ways in which it is excessive. It might be useful if PageGetHeapFreeSpace() usually considered a heap page to have no free space if the number of tuples with storage (or some cheap proxy thereof) was about 227, which is the largest number of distinct heap tuples that can *plausibly* ever be stored on an 8KiB page (it ignores zero column tables). Most current PageGetHeapFreeSpace() callers (including VACUUM) would continue to call that function in the same way as today, and get this lower limit. A few of the existing PageGetHeapFreeSpace() callers could store more line pointers than that (MaxHeapLinePointersPerPage, which might be 510 in practice) -- but only those involved in updates. The overall idea is to recognize that free space is not interchangeable -- updates should have some kind of advantage over plain inserts when it comes to the space on the page of the tuple that they're updating. We might even want to make our newly defined, lower MaxHeapTuplesPerPage into a tunable storage param. -- Peter Geoghegan
