Re: Add pg_stat_autovacuum_priority

From: Andres Freund <andres(at)anarazel(dot)de>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, satyanarlapuram(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, tndrwang(at)gmail(dot)com
Subject: Re: Add pg_stat_autovacuum_priority
Date: 2026-04-09 16:58:13
Message-ID: bdwnlcqyctzjqxfgxqz3ge6mfpmxouxmlrykqzwghcqopfhsy6@wrkr25rmhkms
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Adam Brusselback 2026-04-09 17:32:59 Re: [Patch] Add WHERE clause support to REFRESH MATERIALIZED VIEW
Previous Message Andres Freund 2026-04-09 16:50:48 Re: Compress prune/freeze records with Delta Frame of Reference algorithm