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

On Mon, Aug 5, 2019 at 9:28 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Sun, 4 Aug 2019 00:04:01 -0700 (MST), legrand legrand <legrand_legrand(at)hotmail(dot)com> wrote in <1564902241482-0(dot)post(at)n3(dot)nabble(dot)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.