Re: should vacuum's first heap pass be read-only? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: should vacuum's first heap pass be read-only?
Date
Msg-id CA+TgmoYu+-e+kt6qDmtBaxb2O19v7rcvRY-oK0v0iwjRFc9UTw@mail.gmail.com
Whole thread Raw
In response to Re: should vacuum's first heap pass be read-only?  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: should vacuum's first heap pass be read-only?  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Fri, Apr 1, 2022 at 2:27 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I'm not following. It seems like you're saying that the ability to
> vacuum indexes on their own schedule (based on their own needs) is not
> sufficiently compelling. I think it's very compelling, with enough
> indexes (and maybe not very many).
>
> The conveyor belt doesn't just save I/O from repeated scanning of the
> heap. It may also save on repeated pruning (or just dirtying) of the
> same heap pages again and again, for very little benefit.

I'm also not following. In order to get that benefit, we would have to
sometimes decide to not perform lazy_scan_heap() at the startup of a
vacuum. And in this email I asked you whether it was your idea that we
should always start a vacuum operation with lazy_scan_heap(), and you
said "yes":

http://postgr.es/m/CA+Tgmoa6kVEeurtyeOi3a+rA2XuynwQmJ_s-h4kUn6-bKMMDRw@mail.gmail.com

So I'm completely confused here. If we always start a vacuum with
lazy_scan_heap(), as you said you wanted, then we will not save any
heap scanning.

What am I missing?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: PostgreSQL shutdown modes
Next
From: Robert Haas
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)