Re: Vacuum statistics
Alena Rybakina <a.rybakina@postgrespro.ru>
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Jim Nasby <jnasby@upgrade.com>
Cc: Andrei Zubkov <zubkov@moonset.ru>,
Alexander Korotkov <aekorotkov@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>,
Melanie Plageman <melanieplageman@gmail.com>,
jian he <jian.universality@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>, a.lepikhov@postgrespro.ru
Date: 2024-11-10T20:09:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move wal_buffers_full from PgStat_PendingWalStats to WalUsage
- eaf502747bac 18.0 cited
Attachments
- v12-0003-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v12-0003
- v12-0002-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v12-0002
- v12-0001-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v12-0001
- v12-0004-Add-documentation-about-the-system-views-that-are-us.patch (text/x-patch) patch v12-0004
On 08.11.2024 22:34, Jim Nasby wrote: > >> On Nov 2, 2024, at 7:22 AM, Alena Rybakina >> <a.rybakina@postgrespro.ru> wrote: >> >>>> The second is the interrupts field. It is needed for monitoring to know >>>> do we have them or not, so tracking them on the database level will do >>>> the trick. Interrupt is quite rare event, so once the monitoring system >>>> will catch one the DBA can go to the server log for the details. >>> Just to confirm… by “interrupt” you mean vacuum encountered an error? >> Yes it is. > In that case I feel rather strongly that we should label that as > “errors”. “Interrupt” could mean a few different things, but “error” > is very clear. >> >> I updated patches. I excluded system and user time statistics and >> save number of interrupts only for database.I removed the ability to >> get statistics for all tables, now they can only be obtained for an >> oid table [0], as suggested here. I also renamed the statistics from >> pg_stat_vacuum_tables to pg_stat_get_vacuum_tables and similarly for >> indexes and databases. I noticed that that’s what they’re mostly >> called. Ready for discussion. >> > I think it’s better that the views follow the existing naming > conventions (which don’t include “_get_”; only the functions have that > in their names). Assuming that, the only question becomes > pg_stat_vacuum_* vs pg_stat_*_vacuum. Given the existing precedent of > pg_statio_*, I’m inclined to go with pg_stat_vacuum_*. I have fixed it. -- Regards, Alena Rybakina Postgres Professional