Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

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