Re: nested queries vs. pg_stat_activity
| От | Magnus Hagander |
|---|---|
| Тема | Re: nested queries vs. pg_stat_activity |
| Дата | |
| Msg-id | CABUevEwkC7-yJEOzJ9pP-S7F2oqmo8phiA6seDkkxpopPO+bQg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: nested queries vs. pg_stat_activity (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: nested queries vs. pg_stat_activity
|
| Список | pgsql-hackers |
On Mon, Aug 10, 2020 at 9:51 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Aug 10, 2020 at 12:51 PM legrand legrand
<legrand_legrand@hotmail.com> wrote:
> An other solution is to expose nested queryid, and to join it with pg_stat_statements.
> Actual development trying to add queryid to pg_stat_activity isn't helpfull, because it is only exposing top level one.
> Extension pg_stat_sql_plans (github) propose a function called pg_backend_queryid(pid),
> that gives the expected queryid (that is stored in shared memory for each backend) ...
That'd help people using pg_stat_statements, but not others.
Would it even solve the problem for them? pg_stat_statements collects aggregate stats and not a view of what's happening right now -- so it'd be mixing two different types of values. And it would get worse if the same thing is executed multiple times concurrently.
В списке pgsql-hackers по дате отправления: