On Fri, Apr 8, 2022 at 3:31 PM Peter Geoghegan <p...@bowt.ie> wrote: > What if we miss the opportunity to systematically keep successor > versions of a given logical row on the same heap page over time, due > only to the current low MaxHeapLinePointersPerPage limit of 291? If we > had only been able to "absorb" just a few extra versions in the short > term, we would have had stability (in the sense of being able to > preserve locality among related logical rows) in the long term. We > could have kept everything together, if only we didn't overreact to > what were actually short term, rare perturbations.
Hmm. I wonder if we could teach the system to figure out which of those things is happening. In the case that I'm worried about, when we're considering growing the line pointer array, either the line pointers will be dead or the line pointers will be used but the tuples to which they point will be dead. In the case you describe here, there should be very few dead tuples or line pointers in the page. Maybe when the number of line pointers starts to get big, we refuse to add more without checking the number of dead tuples and dead line pointers and verifying that those numbers are still small. Or, uh, something. One fly in the ointment is that if we refuse to expand the line pointer array, we might extend the relation instead, which is another kind of bloat and thus not great. But if the line pointer array is somehow filling up with tons of dead tuples, we're going to have to extend the relation anyway. I suspect that in some circumstances it's better to just accept that outcome and hope that it leads to some pages becoming empty, thus allowing their line pointer arrays to be reset. -- Robert Haas EDB: http://www.enterprisedb.com
