From: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: timestamp for query in pg_stat_statements |
Date: | 2022-03-06 20:37:00 |
Message-ID: | CALNJ-vSyyEfPWhe2grP-0+bvbe-Hr967Lc2nG-SJ9i0tf-VhdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 5, 2022 at 8:17 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> On Sat, Mar 05, 2022 at 06:10:44PM -0800, Zhihong Yu wrote:
> >
> > Looking at pg_stat_statements, there doesn't seem to be timestamp column
> > for when the underlying query is performed.
> > Since the same query can be run multiple times, the absence of timestamp
> > column makes finding the most recent invocation of the query difficult.
> >
> > Does it make sense to add such a column ?
>
> I don't think it would be that helpful. Why do you need to only know when
> the
> last execution was, but no other details among every other cumulated
> counters?
>
> You should consider using some other tools on top of pg_stat_statements
> (and
> possibly other extensions) that performs snapshot regularly and can show
> you
> all the details at the given frequency.
>
Hi,
The current design of pg_stat_statements doesn't have the concept of
observation.
By observation I mean scenarios where pg_stat_statements is read by people
doing performance tuning.
Here is one example (same query, q, is concerned).
At t1, q is performed, leaving one row in pg_stat_statements with mean_time
of 10.
At t2, operator examines pg_stat_statements and provides some suggestion
for tuning q (which is carried out).
At t3, q is run again leaving the row with mean_time of 9.
Now with two rows for q, how do we know whether the row written at t3 is
prior to or after implementing the suggestion made at t2 ?
Using other tools, a lot of the information in pg_stat_statements would be
duplicated to distinguish the counters recorded w.r.t. tuning operation.
I think pg_stat_statements can do better in this regard.
Cheers
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-03-06 22:13:44 | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Previous Message | Tomas Vondra | 2022-03-06 19:20:02 | Re: row filtering for logical replication |