Hi
po 10. 8. 2020 v 22:21 odesÃlatel Robert Haas
napsal:
> On Mon, Aug 10, 2020 at 4:09 PM Magnus Hagander
> wrote:
> > 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
On Mon, Aug 10, 2020 at 4:09 PM Magnus Hagander wrote:
> 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
On Mon, Aug 10, 2020 at 9:51 PM Robert Haas wrote:
> On Mon, Aug 10, 2020 at 12:51 PM legrand legrand
> 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
On Mon, Aug 10, 2020 at 12:51 PM legrand legrand
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
Hello,
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
On Mon, Aug 10, 2020 at 4:37 PM Robert Haas wrote:
> Is there a way that we can show information about nested queries in
> pg_stat_activity? It's often inconvenient for users when somebody's
> executing a function and it doesn't seem to be finishing as quickly as
> anticipated. You can't really
Is there a way that we can show information about nested queries in
pg_stat_activity? It's often inconvenient for users when somebody's
executing a function and it doesn't seem to be finishing as quickly as
anticipated. You can't really tell where in that function things broke
down. There are a
