Hi Julien, Tue, 2022-01-25 at 18:08 +0800, Julien Rouhaud wrote: > > Are those 4 new counters really worth it? > > The min/max were added to make pg_stat_statements a bit more useful > if you > have nothing else using that extension. But once you setup a tool > that > snapshots the metrics regularly, do you really need to know e.g. > "what was the > maximum execution time in the last 3 years", which will typically be > what > people will retrieve from the non-aux min/max counters, rather than > simply > using your additional tool for better and more precise information?
Of course we can replace old min/max metrics with the new "aux" min/max metrics. It seems reasonable to me because they will have the same behavior until we touch reset_aux. I think we can assume that min/max data is saved somewhere if reset_aux was performed, but how about the backward compatibility? There may be some monitoring solutions that doesn't expect min/max stats reset independently of other statement statistics. It seems highly unlikely to me, because the min/max stats for "the last 3 years" is obvious unusable but maybe someone uses them as a sign of something? Are we need to worry about that? Also, there is one more dramatic consequence of such decision... What min/max values should be returned after the auxiliary reset but before the next statement execution? The NULL values seems reasonable but there was not any NULLs before and backward compatibility seems broken. Another approach is to return the old values of min/max stats and the old aux_stats_since value until the next statement execution but it seems strange when the reset was performed and it doesn't affected any stats instantly. regards, Andrei Zubkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company