Hello!
On 26.01.2022 16:43, Andrei Zubkov wrote:
>>
>> 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.
Let me suggest for your consideration an additional reset request flag
that can be used to synchronize reset in a way similar to interrupt
handling.
External reset can set this flag immediately. Then pg_stat_statements
will wait for the moment when the required query hits into the
statistics and only at this moment really reset the aux statistics,
write a new timestamp and clear the flag. At the time of real reset,
total_time will be determined, and pg_stat_statements can immediately
initialize min and max correctly.
From reset to the next query execution the aux view will give old
correct values so neither NaNs nor NULLs will be required.
Also we can put the value of reset request flag into the aux view to
give feedback to the external application that reset was requested.
With best regards,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
