Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

Andrei Zubkov <zubkov@moonset.ru>

From: Andrei Zubkov <zubkov@moonset.ru>

To: Greg Stark <stark@mit.edu>, "Anton A. Melnikov" <aamelnikov@inbox.ru>, Julien Rouhaud <rjuju123@gmail.com>

Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2022-03-25T10:25:23Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Improve quoting in some error messages
- 07e5e6674233 14.0 cited

Attachments

v6-0001-pg_stat_statements-Track-statement-entry-timestamp.patch (text/x-patch) patch v6-0001

Hi

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