Re: Vacuum statistics - Mailing list pgsql-hackers

From Alena Rybakina
Subject Re: Vacuum statistics
Date
Msg-id 77f1b8bc-b365-4e88-b87b-ced37fabbbf0@yandex.ru
Whole thread Raw
In response to Re: Vacuum statistics  (Alena Rybakina <lena.ribackina@yandex.ru>)
List 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

pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Next
From: Nathan Bossart
Date:
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump