Hacker News Reader

Comment by deepsun | Hacker News Reader

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.

Distributed tracing is a term for tracing that span between systems. With distributed tracing you can follow request traces across your various services. With pg_tracing enabled in postgres this would extend to your database.

Yes, I know I've been using it for a while.

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.

Yeah, this is for integration with OTEL standard distributed tracing. So you configure some OTEL compliant endpoint for postgres to send trace spans to and that endpoint will collect traces from different services and store them for later retrieval.

You have a service that talks to postgres, probably other services that talk to that service, a client that talks to these services through some gateway. When a user clicks a button, distributed tracing allows you to see the whole request right from the button click to API gateway, to every service it goes through to the DB.. and all the way back. So you can see exactly the path it took, where it slowed down or failed. DBs are usually seen as black boxes in such systems. We just see the DB call took 500ms. We don't know what happened inside though. This allows such distributed traces to also get visibility to the internals of the DB so you can tell the exact joins, index scans etc that took place by looking at your distributed trace. I don't know what level of visibility they've built but that's the general idea.

Reply on news.ycombinator.com