| From: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
|---|---|
| To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
| Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: POC: Extension for adding distributed tracing - pg_tracing |
| Date: | 2023-07-28 13:01:44 |
| Message-ID: | CAN-LCVPt=ayjSejTKjzMc-Ncte80k=u+KsgO31pOtK28dh=Ofw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi!
What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT
and INSTR_TIME_GET_MILLISEC
macros for timing calculations?
Also, have you thought about a way to trace existing (running) queries
without directly instrumenting them? It would
be much more usable for maintenance and support personnel, because in
production environments you rarely could
change query text directly. For the current state the most simple solution
is switch tracing on and off by calling SQL
function, and possibly switch tracing for prepared statement the same way,
but not for any random query.
I'll check the patch for the race conditions.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2023-07-28 13:58:21 | Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning |
| Previous Message | Alexander Lakhin | 2023-07-28 13:00:00 | Re: Postgres v15 windows bincheck regression test failures |