Re: Vacuum statistics

From: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Andrei Zubkov <zubkov(at)moonset(dot)ru>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, a(dot)lepikhov(at)postgrespro(dot)ru
Subject: Re: Vacuum statistics
Date: 2024-09-28 21:22:28
Message-ID: 9485d892-fd04-4e3a-ac24-7dd767cb7333@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi! Thank you for your interesting for this patch!
>> I took a very brief look at this and was wondering if it was worth
>> having a way to make the per-table vacuum statistics opt-in (like a
>> table storage parameter) in order to decrease the shared memory
>> footprint of storing the stats.
> I'm not sure how users can select tables that enable vacuum statistics
> as I think they basically want to have statistics for all tables, but
> I see your point. Since the size of PgStat_TableCounts approximately
> tripled by this patch (112 bytes to 320 bytes), it might be worth
> considering ways to reduce the number of entries or reducing the size
> of vacuum statistics.

The main purpose of these statistics is to see abnormal behavior of
vacuum in relation to a table or the database as a whole.

For example, there may be a situation where vacuum has started to run
more often and spends a lot of resources on processing a certain index,
but the size of the index does not change significantly. Moreover, the
table in which this index is located can be much smaller in size. This
may be because the index is bloated and needs to be reindexed.

This is exactly what vacuum statistics can show - we will see that
compared to other objects, vacuum processed more blocks and spent more
time on this index.

Perhaps the vacuum parameters for the index should be set more
aggressively to avoid this in the future.

I suppose that if we turn off statistics collection for a certain
object, we can miss it. In addition, the user may not enable the
parameter for the object in time, because he will forget about it.

As for the second option, now I cannot say which statistics can be
removed, to be honest. So far, they all seem necessary.

--
Regards,
Alena Rybakina
Postgres Professional

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-09-28 22:59:02 Re: pg_verifybackup: TAR format backup verification
Previous Message Andrew Kane 2024-09-28 21:18:15 ORDER BY operator index scans and filtering