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 16:55:53
Message-ID: 81ff87bba41d7405847e9606a443244dca4631d5.camel@moonset.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2021-12-03 at 17:03 +0300, Andrei Zubkov wrote:
> 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 adding new fields to pg_stat_statements view it looks a little
bit overloaded. Furthermore, fields in this view have different
behavior.

What if we'll create a new view for such resettable fields? It will
make description of views and reset functions in the docs much more
clear.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-12-03 17:10:07 Re: pg_dump versus ancient server versions
Previous Message Zhihong Yu 2021-12-03 16:35:58 Re: [PROPOSAL] new diagnostic items for the dynamic sql