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.
