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