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

Kyotaro Horiguchi-4 wrote
> At Sun, 4 Aug 2019 00:04:01 -0700 (MST), legrand legrand <

> legrand_legrand@

> &gt; wrote in <

> 1564902241482-0.post@.nabble

>>
>> >  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

Hi Kyotaro,
Thank you for this answer.
What you propose here is already available 
Inside pg_stat_sql_plans extension (a derivative from 
Pg_stat_statements and pg_store_plans)
And I’m used to this queryid behavior with top Level
Queries...
My emotion was high but I will accept it !
Regards
PAscal




--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html