On Tue, Apr 5, 2022 at 3:22 PM Peter Geoghegan <pg@bowt.ie> wrote:
> It's not just an enabler of more frequent index vacuuming (for those
> indexes that need it the most), though. It's also an enabler of more
> frequent lazy_scan_prune processing (in particular setting hint bits
> and freezing), which is probably even more likely to benefit from the
> decoupling you'd be enabling. I can imagine this having great value in
> a world where autovacuum scheduling eagerly keeps up with inserts into
> an append-mostly table, largely avoiding repeating dirtying within
> lazy_scan_prune, with dynamic feedback. You just need to put off the
> work of index/heap vacuuming to be able to do that kind of thing.
I had assumed that this would not be the case, because if the page is
being accessed by the workload, it can be pruned - and probably frozen
too, if we wanted to write code for that and spend the cycles on it -
and if it isn't, pruning and freezing probably aren't needed.
> But, these same LP_DEAD-heavy tables *also* have a very decent
> chance of benefiting from a better index vacuuming strategy, something
> *also* enabled by the conveyor belt design. So overall, in either scenario,
> VACUUM concentrates on problems that are particular to a given table
> and workload, without being hindered by implementation-level
> restrictions.
Well this is what I'm not sure about. We need to demonstrate that
there are at least some workloads where retiring the LP_DEAD line
pointers doesn't become the dominant concern.
Also, just to be clear, I'm not arguing against my own idea. I'm
trying to figure out what the first, smallest unit of work that
produces a committable patch with a meaningful benefit is.
--
Robert Haas
EDB: http://www.enterprisedb.com