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
