Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

From: Andrei Zubkov <zubkov(at)moonset(dot)ru>
To: Greg Stark <stark(at)mit(dot)edu>, "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date: 2022-03-25 10:25:23
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Fri, 2022-03-25 at 00:37 -0400, Greg Stark wrote:
> Fwiw I find the idea of having a separate "aux" table kind of
> awkward.
> It'll seem strange to users not familiar with the history and without
> any clear idea why the fields are split.

Greg, thank you for your attention and for your thought.

I've just completed the 6th version of a patch implementing idea
proposed by Julien Rouhaud, i.e. without auxiliary statistics. 6th
version will reset current min/max fields to zeros until the first plan
or execute. I've decided to use zeros here because planning statistics
is zero in case of disabled tracking. I think sampling solution could
easily handle this.

Regards, Andrei Zubkov

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2022-03-25 10:26:39 Re: logical decoding and replication of sequences
Previous Message 2022-03-25 10:19:32 RE: Logical replication timeout problem