From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> |
Subject: | Re: POC: Extension for adding distributed tracing - pg_tracing |
Date: | 2024-01-06 23:48:30 |
Message-ID: | CAGECzQQbXrnjJUuKRvgfH=bLtWZggGoAtEg6RhkptZyKq-S=9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 4, 2024, 16:36 Anthonin Bonnefoy
<anthonin(dot)bonnefoy(at)datadoghq(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-01-06 23:54:51 | Re: Multidimensional Histograms |
Previous Message | Geoff Winkless | 2024-01-06 23:27:40 | Re: weird GROUPING SETS and ORDER BY behaviour |