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