Hacker Newsnew | past | comments | ask | show | jobs | submit | deepsun's commentslogin

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.

> pg_tracing only supports PostgreSQL 14, 15 and 16 for the moment.

PostgresSQL is already at 18.


The last couple commits were about pg18 support. Maybe development stalled, but didn't completely stop

Also, tracing support is being upstreamed into Postgres proper https://github.com/DataDog/pg_tracing/issues/86 which would make this extension obsolete


Well, if local police is not cooperating then it's as designed by the constitution (states have the authority to police), to not give federal government powers to make the country a police state. Feature, not a bug. Federals should discuss and persuade the state and their police.

Nobody said the police are not policing. They have their own jobs and not there to do the bidding of the federal government. You're saying this like the local authorities are meant to drop what they are doing at the drop of dime because the feds have a request. These are not dangerous criminals that require a timely response before causing more harm. These are people trying to live their lives and it will not harm the rest of the citizens by doing immigration enforcement at a slower pace.

Did you not notice chasil and deepsun were different accounts?

What does that have to do with my response to the comment I replied?

Your reply to deepsun made no sense as reply to deepsun. You said You're saying this like the local authorities are meant to drop what they are doing at the drop of dime because the feds have a request. But deepsun said the opposite almost.

Well, security is the #1 consideration for SSH, but if the author doesn't need security, why use ssh?

For example, "nc" (netcat) is pre-installed on all platforms where ssh is.


I seem to hit this logic often recently for some reason.

There are two issues with it:

- a primary is not a totality: if "security is the #1 consideration for SSH", that implies there's a #2, maybe even a #3 and so on consideration. So the question that follows becomes tautological: "but if the author doesn't need security, why use ssh?" -> surely for one or more of the #2, #3, etc. considerations, right?

- overabstraction (*): you ended up strawmanning the author. What they had issue with was keystroke timing obfuscation, which is a privacy feature. Timing attacks are (in part) a privacy concern, and privacy is a security concern, yes, but security is not just privacy concern, and privacy concerns are not just about timing attacks; these groups are not equal. For example, they might very well want the transmitted keypresses themselves to remain confidential, or they might very well want to retain cryptographic assurance of their integrity. These are security features they can continue to utilize by sticking with SSH.

All of this is to say, it's not even necessarily them using SSH for a hypothetical #2 or #3 (...etc...) reason, but likely because they still very much want to make use of large chunks of #1, which disabling keypress obfuscation does not actually rid SSH of, only at most weakens it in ways they clearly seem to be okay with.

(*) although if I zoom out enough, this is once again just "a primary is not a totality", just implicitly


> For example, "nc" (netcat) is pre-installed on all platforms where ssh is.

This is technically incorrect, because Windows now includes SSH too!


Depends on what kind of security. They might care about connection integrity. If a faulty (or malicious) router in-between client and server starts malforming packets, `nc` will display those malformed packets. SSH will only show you what the server intended, or nothing.

There's only 50 weekends in a year. And there's a limited amount of years. I'd rather pay $10 and spend the weekend sailing.

> There's only 50 weekends in a year.

That's sad for you. Do you spend the other two weekends dead for tax purposes?


Can we just hallucinate the whole conference by now? Like "Hey AI, generate me the whole conference agenda, schedule, papers, tracks, workshops, and keynote" and not pay the $1k?

Well, except for speed, compression algorithms need to be compared in terms of compression, you know.

Here's discussion by brotli's and zstd's staff:

https://news.ycombinator.com/item?id=19678985


Brotli compresses my files way better, but it's doing it way slower. Anyway, universal statement "zstd is better" is not valid.

On max compression "--ultra -22", zstd is likely to be 2-4% less dense (larger) on text alike input. While taking over 2x times times to compress. Decompression is also much faster, usually over 2x.

I have not tried using a dictionary for zstd.


If not for NATO, Russia would have already invaded Baltic states, same as Ukraine, and maybe Finland.

Why wouldn't Americans want government to act in the interest of their companies (e.g. arms manufacturers)? That's more into GDP, more jobs etc. Unless it takes a business away from other companies, of course. But any American should be glad that, say, Raytheon won a big contract over some company in another country.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: