From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SLRU statistics |
Date: | 2020-02-29 14:44:26 |
Message-ID: | 20200229144426.GA32500@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-Feb-29, Tomas Vondra wrote:
> Did we actually remove track-enabling GUCs? I think we still have
>
> - track_activities
> - track_counts
> - track_io_timing
> - track_functions
>
> But maybe I'm missing something?
Hm I remembered we removed the one for row-level stats
(track_row_stats), but what we really did is merge it with block-level
stats (track_block_stats) into track_counts -- commit 48f7e6439568.
Funnily enough, if you disable that autovacuum won't work, so I'm not
sure it's a very useful tunable. And it definitely has more overhead
than what this new GUC would have.
> > I find SlruType pretty odd, and the accompanying "if" list in
> > pg_stat_get_slru() correspondingly so. Would it be possible to have
> > each SLRU enumerate itself somehow? Maybe add the name in SlruCtlData
> > and query that, somehow. (I don't think we have an array of SlruCtlData
> > anywhere though, so this might be a useless idea.)
>
> Well, maybe. We could have a system to register SLRUs dynamically, but
> the trick here is that by having a fixed predefined number of SLRUs
> simplifies serialization in pgstat.c and so on. I don't think the "if"
> branches in pg_stat_get_slru() are particularly ugly, but maybe we could
> replace the enum with a registry of structs, something like rmgrlist.h.
> It seems like an overkill to me, though.
Yeah, maybe we don't have to fix that now.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2020-02-29 14:45:57 | [REPORT] Possible Memory Leak Postgres Windows |
Previous Message | Fabien COELHO | 2020-02-29 14:39:06 | Re: pgbench: option delaying queries till connections establishment? |