Re: Vacuum statistics
Alena Rybakina <a.rybakina@postgrespro.ru>
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-13T11:29:31Z
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 10.01.2025 17:51, Alena Rybakina wrote: > > 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? I implemented this in my latest patch version [0]. [0] https://www.postgresql.org/message-id/1e81a0a1-a63b-48fb-905a-d6495f89ab73%40postgrespro.ru -- Regards, Alena Rybakina Postgres Professional