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