Feedback-ID: id4a34324:Fastmail
Date: Wed, 8 Apr 2026 18:23:54 -0400
From: Andres Freund <andres@anarazel.de>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>,
	Sami Imseih <samimseih@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: <fcvnawwq32mamvf66q5i3sk73xudxz5corqlgqljtocepspjps@ypvl6yjzy5xk>
References: <adQsdvPPNviWMCXb@nathan>
 <5684f479-858e-4c5d-b8f5-bcf05de1f909@gmail.com>
 <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>
 <3nob5fjwrar3shffl5yo7im4qlnxxa475pi6fohemodsvwpl5g@l5cbmz5dqtjm>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3nob5fjwrar3shffl5yo7im4qlnxxa475pi6fohemodsvwpl5g@l5cbmz5dqtjm>
Archived-At: 
 <https://www.postgresql.org/message-id/fcvnawwq32mamvf66q5i3sk73xudxz5corqlgqljtocepspjps%40ypvl6yjzy5xk>
Precedence: bulk

Hi,

On 2026-04-08 17:59:36 -0400, Andres Freund wrote:
> I don't think it should be quite 16MB for 100k tables though? I see
> 
> ┌────────────────────────┬────────────────┐
> │          name          │ pg_size_pretty │
> ├────────────────────────┼────────────────┤
> │ PgStat Shared Ref      │ 8104 kB        │
> │ PgStat Shared Ref Hash │ 4097 kB        │
> │ CacheMemoryContext     │ 1024 kB        │
> └────────────────────────┴────────────────┘

> after doing
> 
> SELECT sum(score) FROM pg_stat_autovacuum_scores;
> 
> in this database:
> 
> SELECT relkind, count(*) FROM pg_class GROUP BY relkind;
> ┌─────────┬────────┐
> │ relkind │ count  │
> ├─────────┼────────┤
> │ S       │      1 │
> │ i       │    182 │
> │ r       │ 102292 │
> │ t       │     43 │
> │ v       │    167 │
> └─────────┴────────┘
> (5 rows)

(8104 * 1024) / 102292 = 81.13

81 bytes eemed a bit high, given the struct is 48 bytes.

My first thought is that this was from a debug build, where allocations have
more overhead.  And indeed, in an optimized build it's "just" 7248kB, a
per-entry size of 78.78.

A lot of that is probably due to rounding up in aset.c (and perhaps a bit due
to ALLOCSET_SMALL_SIZES).

Since "PgStat Shared Ref" only ever does one type of allocation, it actually
is a good candidate for slab.  In debug that's 7248kB and optimized it's
5632kB, when using a 16kB block size.  The latter is 56 bytes per entry, where
sizeof(PgStat_EntryRef) is 48 bytes. Which is a pretty reasonable allocator
overhead and 16kB seems not too crazy an allocator block size for this?


Note that even if you just \dt in that database, you have a CacheMemoryContext
of 41MB.  If you VACUUM the caches are 121MB.

Greetings,

Andres Freund