| 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: | Whole Thread | Raw Message | 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 |