Re: Vacuum statistics
Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
To: Alena Rybakina <a.rybakina@postgrespro.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: jian he <jian.universality@gmail.com>,
Alexander Korotkov <aekorotkov@gmail.com>, Andrei Zubkov
<zubkov@moonset.ru>, Alena Rybakina <lena.ribackina@yandex.ru>,
a.lepikhov@postgrespro.ru
Date: 2024-11-07T14:49:23Z
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
On 22.10.2024 22:30, Alena Rybakina wrote: > > Hi! > > On 16.10.2024 14:01, Alena Rybakina wrote: >>> >>> Thank you for rebasing. >>> >>> I have noticed that when I create a table or an index on this table, >>> there is no information about the table or index in >>> pg_stat_vacuum_tables and pg_stat_vacuum_indexes until we perform a >>> VACUUM. >>> >>> Example: >>> >>> CREATE TABLE t (i INT, j INT); >>> INSERT INTO t SELECT i/10, i/100 FROM GENERATE_SERIES(1,1000000) i; >>> SELECT * FROM pg_stat_vacuum_tables WHERE relname = 't'; >>> .... >>> (0 rows) >>> CREATE INDEX ON t (i); >>> SELECT * FROM pg_stat_vacuum_indexes WHERE relname = 't_i_idx'; >>> ... >>> (0 rows) >>> >>> I can see the entries after running VACUUM or executing >>> autovacuum. or when autovacuum is executed. I would suggest adding a >>> line about the relation even if it has not yet been processed by >>> vacuum. Interestingly, this issue does not occur with >>> pg_stat_vacuum_database: >>> >>> CREATE DATABASE example_db; >>> SELECT * FROM pg_stat_vacuum_database WHERE dbname = 'example_db'; >>> dboid | dbname | ... >>> ... | example_db | ... >>> (1 row) >>> >>> BTW, I recommend renaming the view pg_stat_vacuum_database to >>> pg_stat_vacuum_database_S_ for consistency with >>> pg_stat_vacuum_tables and pg_stat_vacuum_indexes >>> >> Thanks for the review. I'm investigating this. I agree with the >> renaming, I will do it in the next version of the patch. >> > I fixed it. I added the left outer join to the vacuum views and for > converting the coalesce function from NULL to null values. > > I also fixed the code in getting database statistics - we can get it > through the existing pgstat_fetch_stat_dbentry function and fixed > couple of comments. > > I attached a diff file, as well as new versions of patches. > > -- > Regards, > Alena Rybakina > Postgres Professional Thank you for fixing it. 1) I have found some typos in the test output files (out-files) when running 'make check' and 'make check-world'. These typos might cause minor discrepancies in test results. You may already be aware of them, but I wanted to bring them to your attention in case they haven't been noticed. I believe these can be fixed quickly. 2) Additionally, I observed that when we create a table and insert some rows, executing the VACUUM FULL command does not update the information in the 'pg_stat_get_vacuum_tables' However, running the VACUUM command does update this information as expected. This seems inconsistent, and it might be a bug. Example: CREATE TABLE t (i INT, j INT) WITH (autovacuum_enabled = false); INSERT INTO t SELECT i/10, i/100 FROM GENERATE_SERIES(1,1000000) i; SELECT * FROM pg_stat_get_vacuum_tables WHERE relname = 't'; schema | relname | relid | total_blks_read | ......... -----------+------------+---------+----------------------+--------- public | t | 21416 | 0 | ...... (1 row) VACUUM FULL; SELECT * FROM pg_stat_get_vacuum_tables WHERE relname = 't'; schema | relname | relid | total_blks_read | ......... -----------+------------+---------+----------------------+--------- public | t | 21416 | 0 | ...... (1 row) VACUUM; SELECT * FROM pg_stat_get_vacuum_tables WHERE relname = 't'; schema | relname | relid | total_blks_read | ......... -----------+------------+---------+----------------------+--------- public | t | 21416 | 4425 | ...... (1 row) Regards, Ilia Evdokimov, Tantor Labs LLC.