Horton

Re: Vacuum statistics

Alena Rybakina <a.rybakina@postgrespro.ru>

View thread
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Jim Nasby <jnasby@upgrade.com>, Andrei Zubkov <zubkov@moonset.ru>, Masahiko Sawada <sawada.mshk@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, jian he <jian.universality@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, a.lepikhov@postgrespro.ru
Date: 2025-01-10T14:51:10Z
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 →

  1. Move wal_buffers_full from PgStat_PendingWalStats to WalUsage

Hi! I thought about this problem again and I think I have a solution.

On 02.12.2024 23:12, Alena Rybakina wrote:
>> * I've read the previous discussion on how important to keep all these
>> fields regarding vacuum statistics including points by Andrei and Jim.
>> It still worrying me that statistics volume is going to burst in about
>> 3 times, but I don't have a particular proposal on how to make more
>> granular approach.  I wonder if you could propose something.
We can collect statistics on databases at all times - there are less 
compared to vacuum statistics of relations, but they can give enough 
information that can hint that something is going wrong.
With the track_vacuum_statistics guc we can cover cases of collecting 
extended and complete information: when it is enabled, we will collect 
vacuum statistics on relations both: heaps and indexes.
This will not lead to a synchronicity between constant database 
statistics and temporary statistics of relations, since our vacuum 
statistics are cumulative and it is assumed that we will look at changes 
in statistics over a certain period.
What do you think?

-- 
Regards,
Alena Rybakina
Postgres Professional