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 →
-
Move wal_buffers_full from PgStat_PendingWalStats to WalUsage
- eaf502747bac 18.0 cited
Attachments
- v21-0004-Add-documentation-about-the-system-views-that-are-us.patch (text/x-patch) patch v21-0004
- v21-0003-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v21-0003
- v21-0002-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v21-0002
- v21-0001-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v21-0001
- vacuum_moved_new_entry.diff.no-cfbot (text/plain)
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