| 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 |
| Message-ID: | 00cc23ddbe5c26bb5cc9a9aaebe4a1e1367f6bab.camel@moonset.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v6-0001-pg_stat_statements-Track-statement-entry-timestamp.patch | text/x-patch | 29.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2022-03-25 10:26:39 | Re: logical decoding and replication of sequences |
| Previous Message | wangw.fnst@fujitsu.com | 2022-03-25 10:19:32 | RE: Logical replication timeout problem |