On Mon, Aug 10, 2020 at 9:51 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Aug 10, 2020 at 12:51 PM legrand legrand > <legrand_legr...@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. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
