Re: decoupling table and index vacuum

On Sat, Sep 25, 2021 at 10:17 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Thu, Sep 23, 2021 at 10:42 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > On Thu, Sep 16, 2021 at 7:09 AM Peter Geoghegan <pg(at)bowt(dot)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/