public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: [email protected]
Cc: pgsql-hackers <[email protected]>
Cc: [email protected]
Subject: Re: Add pg_stat_autovacuum_priority
Date: Wed, 8 Apr 2026 18:23:54 -0400
Message-ID: <fcvnawwq32mamvf66q5i3sk73xudxz5corqlgqljtocepspjps@ypvl6yjzy5xk> (raw)
In-Reply-To: <3nob5fjwrar3shffl5yo7im4qlnxxa475pi6fohemodsvwpl5g@l5cbmz5dqtjm>
References: <adQsdvPPNviWMCXb@nathan>
<[email protected]>
<[email protected]>
<adaWuTR7oCKodH7k@nathan>
<[email protected]>
<adan_E0o69p81lIj@nathan>
<[email protected]>
<u3akkfw3vaocviudt6f7ft4kxjc2273rh3tfhz5rfwg6jrcc2t@wurwws6wgjjz>
<adbHYQMZ0pHQttWa@nathan>
<3nob5fjwrar3shffl5yo7im4qlnxxa475pi6fohemodsvwpl5g@l5cbmz5dqtjm>
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
view thread (60+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add pg_stat_autovacuum_priority
In-Reply-To: <fcvnawwq32mamvf66q5i3sk73xudxz5corqlgqljtocepspjps@ypvl6yjzy5xk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox