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
ú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
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
ú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
Hi
We have good API and tools for monitoring slow queries. What is very good.
But I miss a monitoring fast queries what is usually major number and where
relatively small slowdown can to produce unhappy latencies on user
interface. More, the slowdowns here can shows some issues of database
