Hi Julien, On Tue, 2022-01-25 at 20:22 +0800, Julien Rouhaud wrote: > 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.
Thank you, I've just seen a thread in [1], it was of course a weak attempt and I think it could be done better. > > > 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. Agreed. I'm worry about having different solutions running simultaneously. All of them may want to get accurate min/max values, but if they all will reset min/max statistics, they will interfere each other. It seems that min/max resetting should be configurable in each sampler as a partial problem solution. At least, every sampling solution can make a decision based on reset timestamps provided by pg_stat_statements now. > > > 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. I don't know for sure what we can expect to be wrong here. My opinion is to use NULLs, as they seems more suitable here. But this can be done only if we are not expecting significant side effects. -- Andrei Zubkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company