On Wed, 4 Aug 2021 at 15:39, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Aug 3, 2021 at 8:44 PM Peter Geoghegan <p...@bowt.ie> wrote: > > This time it's quite different: we're truncating the line pointer > > array during pruning. Pruning often occurs opportunistically, during > > regular query processing. In fact I'd say that it's far more common > > than pruning by VACUUM. So the chances of line pointer array > > truncation hurting rather than helping seems higher. > > How would it hurt? > > It's easy to see the harm caused by not shortening the line pointer > array when it is possible to do so: we're using up space in the page > that could have been made free. It's not so obvious to me what the > downside of shortening it might be. I suppose there is a risk that we > shorten it and get no benefit, or even shorten it and have to lengthen > it again almost immediately. But neither of those things really > matters unless shortening is expensive. If we can piggy-back it on an > existing WAL record, I don't really see what the problem is.
Hmm, there is no information in WAL to describe the line pointers being truncated by PageTruncateLinePointerArray(). We just truncate every time we see a XLOG_HEAP2_VACUUM record and presume it does the same thing as the original change. If that is safe, then we don't need to put the truncation on a WAL record at all, we just truncate after every XLOG_HEAP2_PRUNE record. If that is not safe... then we have a PG14 bug. If we do want to see this in WAL, both xl_heap_vacuum and xl_heap_prune lend themselves to just adding one more OffsetNumber onto the existing array, to represent the highest offset after truncation. So we don't need to change the WAL format. -- Simon Riggs http://www.EnterpriseDB.com/
