Horton

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: legrand legrand <legrand_legrand@hotmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-08-05T08:35:11Z
Lists: pgsql-hackers 
On Mon, Aug 5, 2019 at 9:28 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Sun, 4 Aug 2019 00:04:01 -0700 (MST), legrand legrand <legrand_legrand@hotmail.com> wrote in <1564902241482-0.post@n3.nabble.com>
> > >  However having the nested queryid in
> > > pg_stat_activity would be convenient to track
> > > what is a long stored functions currently doing.
> >
> > +1
> >
> > And  this could permit to get wait event sampling per queryid when
> > pg_stat_statements.track = all
>
> I'm strongly on this side emotionally, but also I'm on Tom and
> Andres's side that exposing querid that way is not the right
> thing.
>
> Doing that means we don't need exact correspondence between
> top-level query and queryId (in nested or multistatement queries)
> in this patch.  pg_stat_statements will allow us to do the same
> thing by having additional uint64[MaxBackends] array in
> pgssSharedState, instead of expanding PgBackendStatus array in
> core by the same size.

Sure, but the problem with this approach is that all extensions that
compute their own queryid would have to do the same.  I hope that we
can come up with an approach friendlier for those extensions.

Commits

  1. Clarify description of pg_stat_statements columns

  2. Fix wording in description of pg_stat_statements.toplevel

  3. Mention that toplevel is part of pg_stat_statements key.

  4. adjust query id feature to use pg_stat_activity.query_id

  5. Update copyright for 2021

  6. Take the statistics collector out of the loop for monitoring backends'