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
