Re: Vacuum statistics

From: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
To: Jim Nasby <jnasby(at)upgrade(dot)com>
Cc: Andrei Zubkov <zubkov(at)moonset(dot)ru>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, a(dot)lepikhov(at)postgrespro(dot)ru
Subject: Re: Vacuum statistics
Date: 2024-11-10 20:09:41
Message-ID: e2003f94-2075-4183-8298-9d25d8431fb1@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08.11.2024 22:34, Jim Nasby wrote:
>
>> On Nov 2, 2024, at 7:22 AM, Alena Rybakina
>> <a(dot)rybakina(at)postgrespro(dot)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

Attachment Content-Type Size
v12-0003-Machinery-for-grabbing-an-extended-vacuum-statistics.patch text/x-patch 19.8 KB
v12-0002-Machinery-for-grabbing-an-extended-vacuum-statistics.patch text/x-patch 42.0 KB
v12-0001-Machinery-for-grabbing-an-extended-vacuum-statistics.patch text/x-patch 67.7 KB
v12-0004-Add-documentation-about-the-system-views-that-are-us.patch text/x-patch 27.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2024-11-10 21:26:20 [BUG] psql: Make \copy from 'text' and 'csv' formats fail on NUL bytes
Previous Message Tom Lane 2024-11-10 19:20:50 Re: Draft back-branch release notes are up