Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?
Date
Msg-id 20190805.162824.123166397.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?  (legrand legrand <legrand_legrand@hotmail.com>)
Responses Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?  (legrand legrand <legrand_legrand@hotmail.com>)
List pgsql-hackers
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.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pglz performance
Next
From: tushar
Date:
Subject: SSL Connection still showing TLSv1.3 even it is disabled inssl_ciphers