Re: proposal: simple query profile and tracing API
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: simple query profile and tracing API |
| Дата | |
| Msg-id | CAFj8pRDiKt11UDBM-LL3cDmxFwLtA5Bt07bM6OfW8-CBzOACEw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: simple query profile and tracing API (legrand legrand <legrand_legrand@hotmail.com>) |
| Ответы |
Re: proposal: simple query profile and tracing API
|
| Список | pgsql-hackers |
út 13. 11. 2018 v 13:12 odesílatel legrand legrand <legrand_legrand@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
В списке pgsql-hackers по дате отправления: