|From:||Andrei Zubkov <zubkov(at)moonset(dot)ru>|
|To:||"Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thank you for your review!
On Mon, 2021-10-18 at 22:11 +0300, Anton A. Melnikov wrote:
> So i suppose that additional vars loc_min and loc_max is a right way
> to do it.
I've added the following fields to the pg_stat_statements view:
and a function that is able to reset those fields:
CREATE FUNCTION pg_stat_statements_reset_local(IN userid Oid DEFAULT 0,
IN dbid Oid DEFAULT 0,
IN queryid bigint DEFAULT 0
It resets the local fields mentioned above and updates the new field
local_stats_since timestamp with time zone
with the current timestamp. All other statement statistics are remains
unchanged. After the reset _local fields will have NULL values till the
next statement execution.
> And one more thing, if there was a reset of stats between two
> then i think it is the best to ignore the new values,
> since they were obtained for an incomplete period.
> This patch, thanks to the saved time stamp, makes possible
> to determine the presence of reset between samples and
> there should not be a problem to realize such algorithm.
Yes, it seems this is up to the sampling solution. Maybe in some cases
incomplete information will be better than nothing... Anyway we have
all necessary data now.
> The only thing I could suggest to your notice
> is a small cosmetic edit to replace
> the numeric value in #define on line 1429 of pg_stat_statements.c
> by one of the constants defined above.
Hmm. I've left it just like it was before me. But it seems, you are
I've attached a new version of a patch. The first_seen column was
renamed to stats_since - it seems to be more self-explaining to me. But
I'm not sure in the current naming at all.
The tests is not ready yet, but any thoughts about the patch are
welcome right now.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|Next Message||Bharath Rupireddy||2021-12-03 14:04:21||Re: Shouldn't postgres_fdw report warning when it gives up getting result from foreign server?|
|Previous Message||Bharath Rupireddy||2021-12-03 13:56:46||Re: O(n) tasks cause lengthy startups and checkpoints|