Re: POC: Extension for adding distributed tracing - pg_tracing - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: POC: Extension for adding distributed tracing - pg_tracing
Date
Msg-id CAN-LCVMfrDhB1_g+fievB_+N7uHa3vLGHN8YObmxq6KN8uKt_g@mail.gmail.com
Whole thread Raw
In response to Re: POC: Extension for adding distributed tracing - pg_tracing  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
Responses Re: POC: Extension for adding distributed tracing - pg_tracing
List pgsql-hackers
Hi!

Thanks for the improvements!
>Here's a new patch with changes from the previous discussion: 
>- I'm now directly storing nanoseconds duration in the span instead of the instr_time. Using the instr_time macros was a bit awkward as the durations I generate don't necessarily have a starting and ending instr_time. 
>Moving to straight nanoseconds made things clearer from my point of view.
Cool. It could be easily casted to ms for the user.

>- I've added an additional sample rate pg_tracing.sample_rate (on top of the pg_tracing.caller_sample_rate). This one will allow queries to be sampled even without trace information propagated from the caller. 
>Setting this sample rate to 1 will basically trace everything. For now, this will only work when going through the post parse hook. I will add support for prepared statements and cached plans for the next patch.
Cool, I've just made the same improvement and wanted to send a patch a bit later after tests.

>- I've improved how parse spans are created. It's a bit challenging to get the start of a parse as there's no pre parse hook or instrumentation around parse so it's only an estimation.
I've also added a query id field to span and made a table and an sql function that flushes spans to this table instead of returning set or records - it is more convenient for the maintenance to query the table.

--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: add timing information to pg_upgrade
Next
From: Nathan Bossart
Date:
Subject: Re: add timing information to pg_upgrade