Re: Vacuum statistics

Alena Rybakina <a.rybakina@postgrespro.ru>

From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, Andrei Zubkov <zubkov@moonset.ru>, Alena Rybakina <lena.ribackina@yandex.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, a.lepikhov@postgrespro.ru
Date: 2024-08-15T08:49:36Z
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

Hi!

On 13.08.2024 16:18, Ilia Evdokimov wrote:
>
> On 10.8.24 22:37, Andrei Zubkov wrote:
>
>> Hi, Ilia!
>>
>>> Do you consider not to create new table in pg_catalog but to save
>>> statistics in existing table? I mean pg_class or
>>> pg_stat_progress_analyze, pg_stat_progress_vacuum?
>>>
>> Thank you for your interest on our patch!
>>
>> *_progress views is not our case. They hold online statistics while
>> vacuum is in progress. Once work is done on a table the entry is gone
>> from those views. Idea of this patch is the opposite - it doesn't
>> provide online statistics but it accumulates statistics about rosources
>> consumed by all vacuum passes over all relations. It's much closer to
>> the pg_stat_all_tables than pg_stat_progress_vacuum.
>>
>> It seems pg_class is not the right place because it is not a statistic
>> view - it holds the current relation state and haven't anything about
>> the relation workload.
>>
>> Maybe the pg_stat_all_tables is the right place but I have several
>> thoughts about why it is not:
>> - Some statistics provided by this patch is really vacuum specific. I
>> don't think we want them in the relation statistics view.
>> - Postgres is extreamly extensible. I'm sure someday there will be
>> table AMs that does not need the vacuum at all.
>>
>> Right now vacuum specific workload views seems optimal choice to me.
>>
>> Regards,
>
>
> Agreed. They are not god places to store such statistics.
>
>
> I have some suggestions:
>
>  1. pgstatfuncs.c in functions tuplestore_put_for_database() and
>     tuplestore_put_for_relation you can remove 'nulls' array if you're
>     sure that columns cannot be NULL.
>
We need to use this for tuplestore_putvalues function. With this 
function, we fill the table with the values of the statistics.
>
> 1.
>
>
>  2. These functions are almost the same and I would think of writing
>     one function depending of type 'ExtVacReportType'
>
I'm not sure that I fully understand what you mean. Can you explain it 
more clearly, please?

On 13.08.2024 16:37, Ilia Evdokimov wrote:
> And I have one suggestion for pg_stat_vacuum_database: I suppose we 
> should add database's name column after 'dboid' column because it is 
> difficult to read statistics without database's name. We could call it 
> 'datname' just like in 'pg_stat_database' view.
>
Thank you. Fixed.

-- 
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company