Re: Vacuum statistics

Alena Rybakina <a.rybakina@postgrespro.ru>

From: Alena Rybakina <a.rybakina@postgrespro.ru>

To: Alexander Korotkov <aekorotkov@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Cc: Jim Nasby <jnasby@upgrade.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>, Kirill Reshke <reshkekirill@gmail.com>, Andrei Zubkov <zubkov@moonset.ru>, Masahiko Sawada <sawada.mshk@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, jian he <jian.universality@gmail.com>, a.lepikhov@postgrespro.ru, Sami Imseih <samimseih@gmail.com>, vignesh C <vignesh21@gmail.com>

Date: 2025-05-09T12:03:55Z

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

Attachments

v22-0001-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v22-0001
v22-0002-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v22-0002
v22-0003-Machinery-for-grabbing-an-extended-vacuum-statistics.patch (text/x-patch) patch v22-0003
v22-0004-Add-documentation-about-the-system-views-that-are-us.patch (text/x-patch) patch v22-0004
vacuum_stats.diff (text/x-patch) patch

Hi, all!

On 25.03.2025 09:12, Alena Rybakina wrote:
>
> Hi! I rebased the patches again - PGSTAT_FILE_FORMAT_ID needed to be 
> fixed.
>
On 05.02.2025 09:59, Alexander Korotkov wrote:
> What is the point for disabling pgstat_track_vacuum_statistics then?
> I don't see it saves any valuable resources.  The original point by
> Masahiko Sawada was growth of data structures in times [1] (and
> corresponding memory consumption especially with large number of
> tables).  Now, disabling pgstat_track_vacuum_statistics only saves
> some cycles of pgstat_accumulate_extvac_stats(), and that seems
> insignificant.
>
> I see that we use hash tables with static element size.  So, we can't
> save space by dynamically changing entries size on the base of GUC.
> But could we move vacuum statistics to separate hash tables?  When GUC
> is disabled, new hash tables could be just empty.
>
> Links
> 1.https://www.postgresql.org/message-id/CAD21AoD66b3u28n%3D73kudgMp5wiGiyYUN9LuC9z2ka6YTru5Gw%40mail.gmail.com
I did a rebase and finished the part with storing statistics separately 
from the relation statistics - now it is possible to disable the 
collection of statistics for relationsh using gucs and
this allows us to solve the problem with the memory consumed.

For now I have formatted all this as a diff file. The diff file must be 
applied after all patches have been applied. While looking at it I 
noticed that the code requires significant code refactoring, so I will 
do that.

-- 
Regards,
Alena Rybakina
Postgres Professional