Ăș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 : > > * 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 (in an extension with a > planning hook) > > and populate some continuous views as proposed by pipelinedb (a very > flexible solution). > > Yes, I know a trigger is not possible, and overhead of continuous views has > not been verified, > then some high frequency sampling on pg_stat_activity could help (I can > provide examples for f_get_current_queryid(pid), active event for planning > hook, continuous views) > > An other solution: a customized version of pgsentinel (for high frequency > sampling): > I don't believe to sampling method - I talk about less than 10ms queries, I would to see a 2-3ms planning time, 2-5ms waitings - and it means sampling aboy 2ms, what is expensive Regards Pavel > > see > > https://www.postgresql-archive.org/Proposal-Add-accumulated-statistics-for-wait-event-td6030800.html#a6031384 > > Regards > PAscal > > > > -- > Sent from: > http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html > >