On Tue, 3 Aug 2021 at 20:37, Simon Riggs <simon.ri...@enterprisedb.com> wrote: > > On Tue, 3 Aug 2021 at 17:15, Matthias van de Meent > <boekewurm+postg...@gmail.com> wrote: > > > and further future optimizations might include > > > > - Full-page WAL logging of empty pages produced in the checkpointer > > could potentially be optimized to only log 'it's an empty page' > > instead of writing out the full 8kb page, which would help in reducing > > WAL volume. Previously this optimization would never be hit on > > heapam-pages because pages could not become empty again, but right now > > this has real potential for applying an optimization. > > So what you are saying is your small change will cause multiple > additional FPIs in WAL. I don't call that a future optimization, I > call that essential additional work.
I think you misunderstood my statement. The patch does not change more pages than before. The patch only ensures that empty heapam pages are truly empty according to the relevant PageIsEmpty()-macro; which hypothethically allows for optimizations in the checkpointer process that currently (as in, since its inception) writes all changed pages as full page writes (unless turned off). This change makes it easier and more worthwile to implement a further optimization for the checkpointer and/or buffer manager to determine that 1.) this page is now empty, and that 2.) we can therefore write a specialized WAL record specifically tuned for empty pages instead of FPI records. No additional pages are changed, because each time the line pointer array is shrunk, we've already either marked dead tuples as unused (2nd phase vacuum) or removed HOT line pointers / truncated dead tuples to lp_dead line pointers (heap_page_prune). If, instead, you are suggesting that this checkpointer FPI optimization should be part of the patch just because the potential is there, then I disagree. Please pardon me if this was not your intended message, but "you suggested this might be possible after your patch, thus you must implement this" seems like a great way to burn contributor goodwill. The scope of the checkpointer is effectively PostgreSQL's WAL, plus the page formats of all access methods that use the Page-based storage manager (not just table access methods, but also those of indexes). I'm not yet comfortable with hacking in those (sub)systems, nor do I expect to have the time/effort capacity soon to go through all the logic of these access methods to validate the hypothesis that such optimization can be both correctly implemented and worthwile. Patch 2, as I see it, just clears up some leftover stuff from the end of the pg14 release cycle with new insights and research I didn't have at that point in time. As it is a behaviour change for wal-logged actions, it cannot realistically be backported; therefore it is included as an improvement for pg15. Kind regards, Matthias van de Meent
