Re: Vacuum statistics

Alena Rybakina <a.rybakina@postgrespro.ru>

From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Jim Nasby <jnasby@upgrade.com>, vignesh C <vignesh21@gmail.com>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Andrei Zubkov <zubkov@moonset.ru>, Masahiko Sawada <sawada.mshk@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, jian he <jian.universality@gmail.com>, a.lepikhov@postgrespro.ru, Sami Imseih <samimseih@gmail.com>
Date: 2025-03-25T06:12:57Z
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! I rebased the patches again - PGSTAT_FILE_FORMAT_ID needed to be fixed.

On 21.03.2025 22:42, Alena Rybakina wrote:
>
> I will add it and fix the tests but later and I'll explain why.
>
> I'm working on this issue [0] and try have already created new 
> statistics in Statistics Collector to store database and relation 
> vacuum statistics: PGSTAT_KIND_VACUUM_DB and PGSTAT_KIND_VACUUM_RELATION.
>
> Vacuum statistics are saved there instead of relation's and database's 
> statistic structure, but for some reason it is not possible to find 
> them in the hash table when building a snapshot and display them 
> accordingly.
> I have not yet figured out where the error is.
>
> Without solving this problem, committing vacuum statistics is not yet 
> possible. An alternative way for us was to refuse some statistics for 
> now for relations,
> but we could not agree on which statistics should not be displayed yet 
> and for now we are only adding them :).
>
> I understand why this is important to display more vacuum information 
> about vacuum statistics - it will allow us to better understand the 
> problems of incorrect vacuum settings or, for example, notice a bug in 
> its operation.
>
> In order to reduce the memory consumption for storing them for those 
> who are not going to use them, I just realized that we need to create 
> a separate space for storing the statistics
> I mentioned above (PGSTAT_KIND_VACUUM_DB and 
> PGSTAT_KIND_VACUUM_RELATION), there is no other way to do this and I 
> am still trying to complete this functionality.
>
> I doubt that I will have time for this by code freeze date and even if 
> I do, I will hardly have time for a normal review. There's really a 
> lot more to learn related to the stat collector, so
> I'm postponing it to the next commitfest.
>
> Sorry. I'll fix the tests as soon as I finish this part, since they'll 
> most likely either break the same way or in some new way.
>
> Tomorrow or the day after tomorrow I will send a diff patch with what 
> I have already managed to demonstrate the problem, since I need to 
> bring the code to a normal form.
> Maybe someone who worked with the stat collector will suddenly tell me 
> where and what I have implemented incorrectly.
>
I attached also diff version that contains what I was talking about. The 
test case:

create table t (x int);

insert into t select id from generate_series(1,1000) id;

delete from t where id > 900;

vacuum;

select * from pg_stat_vacuum_tables where relname = 't';

-- 
Regards,
Alena Rybakina
Postgres Professional