| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, 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, tndrwang(at)gmail(dot)com |
| Subject: | Re: pgstat vs aset |
| Date: | 2026-04-09 14:50:49 |
| Message-ID: | ade8yYCKmQm26ppc@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 08, 2026 at 07:04:58PM -0400, Andres Freund wrote:
> 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].
>
> [...]
>
> 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
Nice.
> [2] It's a big enough saving that I'm kinda wondering about whether we should
> try to sneak it into 19.
I don't know whether it's appropriate to try to sneak this into v19 at this
point, but it at least seems like a "moment v20 opens for development"
thing. Should we double check there's no meaningful performance
differences? Otherwise, this seems like an easy win.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2026-04-09 15:21:24 | Re: Implement waiting for wal lsn replay: reloaded |
| Previous Message | Andres Freund | 2026-04-09 14:47:03 | Re: Add errdetail() with PID and UID about source of termination signal |