Feedback-ID: id4a34324:Fastmail
Date: Thu, 9 Apr 2026 12:58:13 -0400
From: Andres Freund <andres@anarazel.de>
To: Sami Imseih <samimseih@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Robert Treat <rob@xzilla.net>, satyanarlapuram@gmail.com,
	pgsql-hackers <pgsql-hackers@postgresql.org>, tndrwang@gmail.com
Subject: Re: Add pg_stat_autovacuum_priority
Message-ID: <bdwnlcqyctzjqxfgxqz3ge6mfpmxouxmlrykqzwghcqopfhsy6@wrkr25rmhkms>
References: <3077290.1775668665@sss.pgh.pa.us>
 <adaWuTR7oCKodH7k@nathan>
 <3097984.1775674400@sss.pgh.pa.us>
 <adan_E0o69p81lIj@nathan>
 <3101163.1775676098@sss.pgh.pa.us>
 <u3akkfw3vaocviudt6f7ft4kxjc2273rh3tfhz5rfwg6jrcc2t@wurwws6wgjjz>
 <adbHYQMZ0pHQttWa@nathan>
 <CAA5RZ0uL1ukKvV0Gwgok9ut_203q_E_tzBrwhDAuJCKVNwWZVw@mail.gmail.com>
 <adbNL1puSbBi8nMo@nathan>
 <CAA5RZ0uiqzLPvZMXsooFPR5udpXUiVy8WvTLbduOvT2JPawYkA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA5RZ0uiqzLPvZMXsooFPR5udpXUiVy8WvTLbduOvT2JPawYkA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/bdwnlcqyctzjqxfgxqz3ge6mfpmxouxmlrykqzwghcqopfhsy6%40wrkr25rmhkms>
Precedence: bulk

Hi,

On 2026-04-08 18:51:59 -0500, Sami Imseih wrote:
> There may be some opportunities to improve other call sites if they
> are indeed leaking.
> For example,  pgstat_copy_relation_stats() could leak with
> fetch_consistency = NONE.

Hard to believe that could be relevant, given it's used when reindexing
concurrently.  Compared to the amount of memory that will use, leaving a small
bit of memory around until the end of the statement is likely hard to even
measure.


> I kept that out for now, but we should probably close that gap in another
> patch.  Also, pgstat_fetch_stat_dbentry() in autovacuum.c could potentially
> use this, but I did not look into detail.

Probably fine, it's a temporary context that's just used for building the
list. You'd have to have a lot of databases for this to be a relevant
factor. The whole function fundamentally uses O(databases) memory, making the
constant factor a bit bigger doesn't seem reelvant.

Greetings,

Andres Freund