Hi, On 2021-02-24 21:15:14 +0500, Alexey Lesovsky wrote: > pg_stat_aios. > In general, this stat is a set of text values, and at the same time it looks > GAUGE-like (similar to pg_stat_activity or pg_locks), and is only relevant > for the moment when the user is looking at it. I think it would be better to > rename this view to pg_stat_progress_aios. And keep pg_stat_aios for other > AIO stats with global COUNTERs (like stuff in pg_stat_user_tables or > pg_stat_statements, or system-wide /proc/stat, /proc/diskstats).
Right - arguably it really shouldn't even have _stat_ in the name... I don't particularly like the idea of adding _progress_ as that seems it'd lead to confusing it with pg_stat_progress_vacuum etc - and it's quite a different beast. > pg_stat_aio_backends. > This stat is based on COUNTERs, which is great, but the issue here is that > its lifespan is limited by the lifespan of the backend processes - once the > backend exits the stat will no longer be available - which could be > inappropriate in workloads with short-lived backends. There's a todo somewhere to roll over the per-connection stats into a global stats piece on disconnect. In addition I was thinking of adding a view that sums up the value of "already disconnected backends" and the currently connected ones. Would that mostly address your concerns? > I think there might be few existing examples in the current code that could > be repurposed to implement the suggestions above (such as > pg_stat_user_tables, pg_stat_database, etc). With this in mind, I think > having these changes incorporated shouldn’t take significant effort > considering the benefit it will bring to the final user. Yea - I kind of was planning to go somewhere roughly in the direction you suggest, but took a few shortcuts due to the size of the project. Having the views made it a lot easier to debug / develop, but supporting longer lived stuff wasn't yet crucial. But I agree, we really should have it... Greetings, Andres Freund
