Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

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
Date: 2021-12-03 14:03:46
Message-ID: ea2a48a107a8dcb9a150fc9304427f5271d194d3.camel@moonset.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Anton!

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:

min_plan_time_local float8,
max_plan_time_local float8,
min_exec_time_local float8,
max_exec_time_local float8

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
> samples,
> 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
right.

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.

--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
v4-0001-pg_stat_statements-Track-statement-entry-timestamp.patch text/x-patch 24.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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