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
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 |