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 →
  1. Move wal_buffers_full from PgStat_PendingWalStats to WalUsage

Attachments

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