Re: Count and log pages set all-frozen by vacuum

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Alastair Turner <minion(at)decodable(dot)me>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Count and log pages set all-frozen by vacuum
Date: 2024-10-31 16:02:17
Message-ID: CA+TgmoYE5_yvuhjg5cv=8s1CUPptQKOdqwBoP97t3zAtfDpxog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2024 at 11:49 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> The emphasis on the work that one particular VACUUM operation
> performed doesn't seem like the most relevant thing to users (I get
> why you'd care about it in the context of your work, though). What
> matters to users is that the overall picture over time is one where
> VACUUM doesn't leave an excessive number of pages
> not-all-frozen-in-VM.

I don't see it quite the same way. I agree that what users are really
concerned about is the excessive number of unfrozen pages in the VM.
But that's not the question here. The question is what should
log_autovacuum_min_duration log. And I think it should log what the
vacuum itself did, not what the state of the table ended up being
around the time the vacuum ended.

And I think there is certainly a use case for knowing how much work of
each particular kind vacuum did. You might for example be trying to
judge whether a particular vacuum was useless. Knowing the cumulative
state of the table around the time the vacuum finished doesn't help
you figure that out; a count of how much work the vacuum itself did
does.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-10-31 16:06:25 Re: small pg_combinebackup improvements
Previous Message Alastair Turner 2024-10-31 15:56:46 Re: Count and log pages set all-frozen by vacuum