Hi Andrei, On Tue, Jan 25, 2022 at 02:58:17PM +0300, Andrei Zubkov wrote: > > 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?
To be honest I don't see how any monitoring solution could make any use of those fields as-is. For that reason in PoWA we unfortunately have to entirely ignore them. There was a previous attempt to provide a way to reset those counters only (see [1]), but it was returned with feedback due to lack of TLC from the author. > Are we need to worry about that? I don't think it's a problem, as once you have a solution on top of pg_stat_statements, you get information order of magnitude better from that solution instead of pg_stat_statements. And if that's a problem, well either don't reset those counters, or don't use the external solution if it does it automatically and you're not ok with it. > 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. If you're worried about some external table having a NOT NULL constraint for those fields, how about returning NaN instead? That's a valid value for a double precision data type. [1] https://www.postgresql.org/message-id/1762890.8ARNpCrDLI@peanuts2
