Re: Add pg_stat_autovacuum_priority - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Add pg_stat_autovacuum_priority
Date
Msg-id bdwnlcqyctzjqxfgxqz3ge6mfpmxouxmlrykqzwghcqopfhsy6@wrkr25rmhkms
Whole thread
In response to Re: Add pg_stat_autovacuum_priority  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm
Next
From: Adam Brusselback
Date:
Subject: Re: [Patch] Add WHERE clause support to REFRESH MATERIALIZED VIEW