Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: Andrei Zubkov <zubkov(at)moonset(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>, "Anton A(dot)Melnikov" <aamelnikov(at)inbox(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2022-01-14 15:15:42
Message-ID: 8ae0160f11baa12eae4793e3da5345066685e4b7.camel@moonset.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On Sun, 2022-01-02 at 13:28 -0800, Andres Freund wrote:
> Hi,
>
> This fails with an assertion failure:
> https://cirrus-ci.com/task/5567540742062080?logs=cores#L55
>
>
Andres, thank you for your test! I've missed it. Fixed in attached
patch v5.

On Wed, 2021-12-22 at 04:25 +0300, Anton A. Melnikov wrote:
>
>
> I completely agree that creating a separate view for these new fields
> is
> the most correct thing to do.

Anton,

I've created a new view named pg_stat_statements_aux. But for now both
views are using the same function pg_stat_statements which returns all
fields. It seems reasonable to me - if sampling solution will need all
values it can query the function.

> Also it might be better to use the term 'auxiliary' and use the same
> approach as for existent similar vars.

Agreed, renamed to auxiliary term.

> So internally it might look something like this:
>
> double aux_min_time[PGSS_NUMKIND];
> double aux_max_time[PGSS_NUMKIND];
> TimestampTz aux_stats_reset;
>
> And at the view level:
> aux_min_plan_time float8,
> aux_max_plan_time float8,
> aux_min_exec_time float8,
> aux_max_exec_time float8,
> aux_stats_reset timestamp with time zone
>
> Functions names might be pg_stat_statements_aux() and
> pg_stat_statements_aux_reset().
>

But it seems "stats_reset" term is not quite correct in this case. The
"stats_since" field holds the timestamp of hashtable entry, but not the
reset time. The same applies to aux_stats_since - for new statement it
holds its entry time, but in case of reset it will hold the reset time.

"stats_reset" name seems a little bit confusing to me.

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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-01-14 15:33:08 Re: Undocumented error
Previous Message Fabrice Chapuis 2022-01-14 15:12:13 Re: Logical replication timeout problem