pgstat vs aset

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
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>, Sami Imseih <samimseih(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, 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: pgstat vs aset
Date: 2026-04-08 23:04:58
Message-ID: rtskcyc2o6rt7yebeej4byb62fnv7mcbuiodyuduqmi4ek2mnn@y5pqlz5fbsbd
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

In [1] I looked at pgstat memory usage after sort of a complaint by Nathan.
The conversion of "PgStat Shared Ref" to slab seems like an improvement we
obviously should make [2].

In the email I also showed how much CacheMemoryContext using a lot of memory
after doing a database wide VACUUM (with ~100k tables), not very surprising.

I didn't immediately look at the next few entries:
┌────────────────────────┬─────────────┬───────────────┬────────────┬─────────────┬────────────┐
│ name │ total_bytes │ total_nblocks │ free_bytes │ free_chunks │ used_bytes │
├────────────────────────┼─────────────┼───────────────┼────────────┼─────────────┼────────────┤
│ CacheMemoryContext │ 168820784 │ 31 │ 2363064 │ 33 │ 166457720 │
│ PgStat Pending │ 27983872 │ 3419 │ 27846912 │ 112699 │ 136960 │
│ smgr relation table │ 16777216 │ 12 │ 2797592 │ 50 │ 13979624 │
│ MdSmgr │ 8388608 │ 11 │ 3475256 │ 1 │ 4913352 │
│ PgStat Shared Ref │ 5767344 │ 88 │ 19712 │ 352 │ 5747632 │
│ PgStat Shared Ref Hash │ 4195376 │ 2 │ 712 │ 0 │ 4194664 │
│ Relcache by OID │ 4194304 │ 10 │ 57448 │ 24 │ 4136856 │
│ TopMemoryContext │ 173264 │ 7 │ 32968 │ 79 │ 140296 │
└────────────────────────┴─────────────┴───────────────┴────────────┴─────────────┴────────────┘

When I did I was quite surprised to see "PgStat Pending" using so much, as it
should all be freed after the stats have been submitted, a few seconds later
at most.

After a moment of worry about having introduced a leak, and adding the
necessary columns to see more information, it's clear that all the memory was
actually freed. It's just that we don't ever free aset blocks, even if all the
constituent memory has been freed. So the overall context size doesn't shrink.

That seems decidedly not great.

I wonder how bad it would be to teach aset to recognize this situation.

But I think for this use case we actually have a more fitting memory context
type for this workload, i.e. GenerationContext. With that the size after the
same vacuum is

│ PgStat Pending │ 134144 │ 3 │ 133848 │ 0 │ 296 │

Seems like a fairly obvious change.

My local experimental changes attached.

Greetings,

Andres Freund

[1] https://postgr.es/m/fcvnawwq32mamvf66q5i3sk73xudxz5corqlgqljtocepspjps%40ypvl6yjzy5xk
[2] It's a big enough saving that I'm kinda wondering about whether we should
try to sneak it into 19.

Attachment Content-Type Size
pgstat-memory.diff text/x-diff 1.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-04-08 23:30:42 Add missing period to HINT messages
Previous Message Andres Freund 2026-04-08 22:23:54 Re: Add pg_stat_autovacuum_priority