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