Re: Vacuum statistics - Mailing list pgsql-hackers

From Alena Rybakina
Subject Re: Vacuum statistics
Date
Msg-id cb305107-5935-4c34-9847-6ff0fef89f06@yandex.ru
Whole thread
In response to Re: Vacuum statistics  (Karina Litskevich <litskevichkarina@gmail.com>)
List pgsql-hackers
Hi Karina,
Thank you for the review!  v44 is attached.


On Wed, Sep 23, 2026 at 8:57 AM Karina Litskevich
<litskevichkarina@gmail.com> wrote:
 > CI is complaining about more than one definition of
 > <table id="extvacuumstatistics-pg-stats-vacuum-indexes-columns">

Fixed, the extra table is removed from 0007.


 > If you add a new external function in
 > visibilitymap.c, i.e., visibilitymap_clear_rel, you should also
 > add it in the INTERFACE ROUTINES list in the beginning of the file.

Done.


 > I'd also suggest that the variation of the visibilitymap_clear
 > function taking a Relation should be the main one (and be called
 > visibilitymap_clear), and the variant taking a RelFileLocator
 > should be the additional one for those who don't have a Relation
 > (and be called visibilitymap_clear_no_stats or something). I am
 > not insisting, though.

I left it as is for now.  Master has just changed visibilitymap_clear() 
to take a RelFileLocator, and I didn't want to change it back.  I can 
rename it if others prefer.


I also changed one more thing in 0004, after a question from Vlada 
Pogozheskaya <v.pogozheskaya@postgrespro.ru>. vacuum_interrupt_count is 
now added to the database stats in pgstat_update_dbstats(), the same way 
as xact_rollback, instead of in AtEOXact_PgStat_Database().
So nothing is done during transaction abort anymore.

--
Regards,
Alena Rybakina
Yandex

Attachment

pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18
Next
From: Peter Eisentraut
Date:
Subject: convert CI CompilerWarnings job to meson