FRESH

Hacker News

Pg_tracing: Distributed Tracing for PostgreSQL

133 points by tanelpoder

by dujuku

0 subcomment

It would be awesome if this were to make it in core. Jelte did a bunch of work to improve query protocol changes. Having Postgres accept Otel trace propagation would be a gamechanger for debugging the clients and DB together. Especially since ~80%+ of DB related issues I see come down to some sort of long running open transaction which Postgres knows nothing about server-side.

by tetha

0 subcomment

This looks very useful for our database heavy teams.
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.

by jakozaur

0 subcomment

Great idea. Currently, people have to rely on client-side spans in OpenTelemetry. However, it would be awesome if we could get spans for slow SQL queries, along with explanations.

by brunoqc

2 subcomments

by 9dev

0 subcomment

Is someone from Sentry here? It’d be amazing if you’d pick this up and extend your tracing into Postgres…

by deepsun

2 subcomments

There's nothing "distributed" about it (the only word that got me click).
The database you send the traces to may be distributed, just like any database, but pg_tracing does nothing for it.