> 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.
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