Re: Resume vacuum and autovacuum from interruption and cancellation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Resume vacuum and autovacuum from interruption and cancellation
Date
Msg-id CA+TgmobwzH9bVQ-MrFNLjb0003CKO0P+f1Q8apRx7-hjpy6qMg@mail.gmail.com
Whole thread Raw
In response to Re: Resume vacuum and autovacuum from interruption and cancellation  (Rafia Sabih <rafia.pghackers@gmail.com>)
Responses Re: Resume vacuum and autovacuum from interruption and cancellation  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih <rafia.pghackers@gmail.com> wrote:
> Sounds like an interesting idea, but does it really help? Because if
> vacuum was interrupted previously, wouldn't it already know the dead
> tuples, etc in the next run quite quickly, as the VM, FSM is already
> updated for the page in the previous run.

+1. I don't deny that a patch like this could sometimes save
something, but it doesn't seem like it would save all that much all
that often. If your autovacuum runs are being frequently cancelled,
that's going to be a big problem, I think. And as Rafia says, even
though you might do a little extra work reclaiming garbage from
subsequently-modified pages toward the beginning of the table, it
would be unusual if they'd *all* been modified. Plus, if they've
recently been modified, they're more likely to be in cache.

I think this patch really needs a test scenario or demonstration of
some kind to prove that it produces a measurable benefit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: 64 bit transaction id
Next
From: Tomas Vondra
Date:
Subject: Re: 64 bit transaction id