PostgresSQL is already at 18.
Also, tracing support is being upstreamed into Postgres proper https://github.com/DataDog/pg_tracing/issues/86 which would make this extension obsolete
Warning
This extension is still in early development and may be unstable.
The database you send the traces to may be distributed, just like any database, but pg_tracing does nothing for it.
The hard part is to merge one trace between storage workers, that's where distributed part comes. pg_tracing does nothing for it.
UPDATE: ah I believe I see what you mean -- that it passes down the trace ID.
Getting this information is certainly already possible, but there is a bit of a barrier in front of it. You need to realize the query is slow, then you need to re-run it with the right EXPLAIN and/or ANALYZE incantation with 8-9 parameters for a query visualizer, paste it into a query visualizer and then you get some nice, easily digested overview of what is going on.
Teams either don't know how to do that, or don't do that, due to permissions or because it's a hassle. Having a slow "calculateFooReport()" trace go straight into a bunch of slow SequentialScan- and NestedLoop-Nodes would remove one excuse from that equation.
Kinda bummed that we're updating out of the supported versions starting next month.
dujuku•1w ago