Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view? |
Дата | |
Msg-id | 20190805.162824.123166397.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view? (legrand legrand <legrand_legrand@hotmail.com>) |
Ответы |
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?
Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view? |
Список | 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 по дате отправления: