Re: Vacuum statistics

From: Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Jim Nasby <jnasby(at)upgrade(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andrei Zubkov <zubkov(at)moonset(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
Subject: Re: Vacuum statistics
Date: 2026-03-09 15:46:14
Message-ID: 77f1b8bc-b365-4e88-b87b-ced37fabbbf0@yandex.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I discovered that my last patches were incorrectly formed. I updated the
correct version.

On 09.03.2026 18:25, Alena Rybakina wrote:
> I developed a patch with a different approach - using custom
> statistics. As in the previous approach, I store statistics separately
> in slots for relations and for databases. It was also necessary to
> introduce a hook, and all control is handled through an extension.
> Statistics collection in the core occurs only if the hook is defined
> (i.e., the extension is added to shared_preload_libraries).
> The extension is also controlled by additional gucs that allow
> disabling vacuum statistics collection, or collecting statistics only
> for system relations, only for user relations, or only at the database
> or relation level.
>
> For now, I have divided them into several categories: general
> statistics (including the number of removed tables and tuples, and how
> many times wraparound prevention occurred), cost-based statistics,
> buffer statistics, and timing statistics. Memory is dynamically freed
> or allocated when the corresponding guc configuration changes. This
> approach is still a work in progress.
>
> In the README and documentation in the extension, I also added
> information about how much memory will be used to store the objects
> (approximately 300 KB) and added the function to measure memory
> consumption.
>
> Currently there are three patches:
> The first patch still collects statistics about frozen pages and pages
> where the visibility flag is cleared.
> The second patch implements statistics collection in the core, but
> without storing them.
>
> The third patch is the extension itself, where the statistics are
> stored and displayed, with the control mechanisms described above.
>
>
> -----------
> Best regards,
> Alena Rybakina

Attachment Content-Type Size
v29-0001-Introduce-new-statistics-tracking-the-number-of-time.patch text/plain 9.3 KB
v29-0002-Machinery-for-grabbing-extended-vacuum-statistics.patch text/plain 17.9 KB
v29-0003-ext_vacuum_statistics-extension-for-extended-vacuum-.patch text/plain 143.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-03-09 15:51:01 Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Previous Message Sami Imseih 2026-03-09 15:44:58 Re: Add starelid, attnum to pg_stats and leverage this in pg_dump