On Sat, Mar 5, 2022 at 8:17 PM Julien Rouhaud <rjuju...@gmail.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
