From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Andrei Zubkov <zubkov(at)moonset(dot)ru>, Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>, a(dot)lepikhov(at)postgrespro(dot)ru |
Subject: | Re: Vacuum statistics |
Date: | 2024-11-07 14:49:23 |
Message-ID: | 52ca6a89-d19d-4df9-ac4b-95548500bf8b@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2024-11-07 14:51:51 | Re: general purpose array_sort |
Previous Message | Robert Haas | 2024-11-07 14:29:05 | Re: general purpose array_sort |