On Sun, Mar 06, 2022 at 07:10:49PM -0800, Zhihong Yu wrote:
> On Sun, Mar 6, 2022 at 6:23 PM Julien Rouhaud wrote:
>
> > On Sun, Mar 06, 2022 at 12:37:00PM -0800, Zhihong Yu wrote:
> > >
> > > Here is one example (same query, q, is concerned).
> > > At t1, q is performed, leaving one row in pg_st
On Sun, Mar 6, 2022 at 6:23 PM Julien Rouhaud wrote:
> On Sun, Mar 06, 2022 at 12:37:00PM -0800, Zhihong Yu wrote:
> > 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
> > doi
On Sun, Mar 06, 2022 at 12:37:00PM -0800, Zhihong Yu wrote:
> 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 con
On Sat, Mar 5, 2022 at 8:17 PM Julien Rouhaud 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, t
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 in
Hi,
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
