On Sat, Sep 25, 2021 at 10:17 AM Peter Geoghegan <p...@bowt.ie> wrote: > > On Thu, Sep 23, 2021 at 10:42 PM Masahiko Sawada <sawada.m...@gmail.com> > wrote: > > On Thu, Sep 16, 2021 at 7:09 AM Peter Geoghegan <p...@bowt.ie> wrote: > > > Enabling index-only scans is a good enough reason to pursue this > > > project, even on its own. > > > > +1 > > I was hoping that you might be able to work on opportunistically > freezing whole pages for Postgres 15. I think that it would make sense > to opportunistically make a page that is about to become all_visible > during VACUUM become all_frozen instead. Our goal is to make most > pages skip all_visible, and go straight to all_frozen directly. Often > the page won't need to be dirtied again, ever.
+1. I'm happy to work on this. There was a similar proposal before[1]; if we freeze even one tuple in a page, we freeze all tuples in a page and set the page as all-frozen if all tuples in the page can be frozen. This is also a good approach. > The hard part is getting the cost way down. lazy_scan_prune() uses > xl_heap_freeze_tuple records for each tuple it freezes. These > obviously have a lot of redundancy across tuples from the same page in > practice. And the WAL overhead is much larger just because these are > per-tuple records, not per-page records. xl_heap_freeze_page includes multiple xl_heap_freeze_tuple data but we write XLOG_HEAP2_FREEZE_PAGE WAL record per pages? What the WAL overhead did you refer to? Regards, [1] https://www.postgresql.org/message-id/CANP8%2Bj%2BEfLZMux6KLvb%2BumdeVYc%2BJZs5ReNSFq9WDLn%2BAKnhkg%40mail.gmail.com -- Masahiko Sawada EDB: https://www.enterprisedb.com/
