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
