Re: POC: Extension for adding distributed tracing - pg_tracing
От | Jelte Fennema-Nio |
---|---|
Тема | Re: POC: Extension for adding distributed tracing - pg_tracing |
Дата | |
Msg-id | CAGECzQQbXrnjJUuKRvgfH=bLtWZggGoAtEg6RhkptZyKq-S=9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: Extension for adding distributed tracing - pg_tracing (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>) |
Ответы |
Re: POC: Extension for adding distributed tracing - pg_tracing
|
Список | pgsql-hackers |
On Thu, Jan 4, 2024, 16:36 Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> wrote: > > I used GUCs to set the `opentelemtery_trace_id` and `opentelemetry_span_id`. > > These can be sent as protocol-level messages by the client driver if the > > client driver has native trace integration enabled, in which case the user > > doesn't need to see or care. And for other drivers, the application can use > > `SET` or `SET LOCAL` to assign them. > > Emitting `SET` and `SET LOCAL` for every traced statement sounds more > disruptive and expensive than relying on SQLCommenter. When not using > `SET LOCAL`, the variables also need to be cleared. > This will also introduce a lot of headaches as the `SET` themselves > could be traced and generate spans when tracing utility statements is > already tricky enough. I think one hugely important benefit of using GUCs over sql comments is, that comments and named protocol-level prepared statements cannot be combined afaict. Since with named protocol level prepared statements no query is sent, only arguments. So there's no place to attach a comment too.
В списке pgsql-hackers по дате отправления: