Re: POC: Extension for adding distributed tracing - pg_tracing
| От | Anthonin Bonnefoy |
|---|---|
| Тема | Re: POC: Extension for adding distributed tracing - pg_tracing |
| Дата | |
| Msg-id | CAO6_XqpYoNO+KECNLkegQ3C4zoEr4iGL6_91QYw4TanwoFt5pw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: POC: Extension for adding distributed tracing - pg_tracing (Nikita Malakhov <hukutoc@gmail.com>) |
| Ответы |
Re: POC: Extension for adding distributed tracing - pg_tracing
|
| Список | pgsql-hackers |
> What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT and INSTR_TIME_GET_MILLISEC
> macros for timing calculations?
If you're talking of the two instances where I'm modifying the instr_time's ticks, it's because I can't use the macros there.
The first case is for the parse span. I only have the start timestamp using GetCurrentStatementStartTimestamp and don't
have access to the start instr_time so I need to build the duration from 2 timestamps.
The second case is when building node spans from the planstate. I directly have the duration from Instrumentation.
I guess one fix would be to use an int64 for the span duration to directly store nanoseconds instead of an instr_time
but I do use the instrumentation macros outside of those two cases to get the duration of other spans.
> Also, have you thought about a way to trace existing (running) queries without directly instrumenting them?
That's a good point. I was focusing on leaving the sampling decision to the caller through the sampled flag and
only recently added the pg_tracing_sample_rate parameter to give more control. It should be straightforward to
add an option to create standalone traces based on sample rate alone. This way, setting the sample rate to 1
would force the queries running in the session to be traced.
On Fri, Jul 28, 2023 at 3:02 PM Nikita Malakhov <hukutoc@gmail.com> wrote:
Hi!What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT and INSTR_TIME_GET_MILLISECmacros for timing calculations?Also, have you thought about a way to trace existing (running) queries without directly instrumenting them? It wouldbe much more usable for maintenance and support personnel, because in production environments you rarely couldchange query text directly. For the current state the most simple solution is switch tracing on and off by calling SQLfunction, 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.--
В списке pgsql-hackers по дате отправления: