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