st 14. 11. 2018 v 14:06 odesílatel legrand legrand <
legrand_legr...@hotmail.com> napsal:
> Pavel Stehule wrote
> > út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
>
> > tomas.vondra@
>
> >> napsal:
> >
> > My idea is very simple.
> >
> > 1. continual collect of data - planning start, execution
Pavel Stehule wrote
> út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
> tomas.vondra@
>> napsal:
>
> My idea is very simple.
>
> 1. continual collect of data - planning start, execution start, waiting
> start, waiting end, query end
>
> 2. run a some callback function after query is finished
út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
tomas.von...@2ndquadrant.com> napsal:
> On Tue, 2018-11-13 at 13:55 +0100, Pavel Stehule wrote:
> > út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
> > legrand_legr...@hotmail.com> napsal:
> >
> > > Hello Pavel,
> > >
> > > What about using wa
On Tue, 2018-11-13 at 13:55 +0100, Pavel Stehule wrote:
> út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
> legrand_legr...@hotmail.com> napsal:
>
> > Hello Pavel,
> >
> > What about using wait events and a trigger on pg_stat_activity ?
> >
>
> pg_stat_activity should not to show fresh dat
út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
legrand_legr...@hotmail.com> napsal:
> Hello Pavel,
>
> What about using wait events and a trigger on pg_stat_activity ?
>
pg_stat_activity should not to show fresh data. Using pg_stat_activity can
be too expensive for fast queries
> just :
>
Hello Pavel,
What about using wait events and a trigger on pg_stat_activity ?
just :
* create a functions to get current query signature (queryid) for a pid
(not the top_level_query given for pl/pgsql blocks or triggers but the
active one)
* add some kind of active events to track planning (i
