Hacker News Reader

Comment by mattmanser | Hacker News Reader

No, you can't use 'negigibly' worse as a defence.

It's either better, or not. Your comment does not make it better, it's still worse. So it won't improve performance, but degrade it, even if it's negilible.

So there's no reason to do it.

Plus you've made a crazy SQL select instead of a normal one, which is harder to maintain.

So it's worse performance and worse maintenance.

i.e. don't do this, it's dumb, especially for the reasons claimed which are factually incorrect as it will not improve throughout but make it worse

View on HN

> you can't use 'negigibly' worse as a defence

Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off of optimizing a more constrained supply (CPU or memory).

> made a crazy SQL select instead of a normal one, which is harder to maintain.

Purely subjective. Myself nor the people I've hired would have a problem maintaining a more complex SQL query using CTE's and JSON serialization than not.

> it's worse performance

I cannot imagine that's the case in the context we've been discussing. An RDBMS duplicating JSON output of tuples multiple times in a single transaction is not particularly expensive compared to the alternative.

The funnest part of outputting JSON from the query is that your API now basically becomes a RPC, as you don't have to do any marshalling/deserialization before returning the response with Content-Type application/json

Response times are really fast like that, as you probably already know. Always fun to see <10ms round trips in the browser network tab on some requests

Also no worry about n+1 queries, as they're fundamentally impossible to do like that

I've long wondered if there would be any performance advantage for an API server to zero-copy the DB response to the browser, deserializing from the DB wire protocol on the front end.

Or perhaps sending DB query results directly from DB server to browser, with the API server just initializing and securing.

Thanks for pointing out how JSON from the DB is another option for moving a bit of processing elsewhere in the stack.

TLS everywhere makes the whole point of zero copying obsolete. Encryption eats so much CPU that copying data around does not change anything.

It does add a few ms, but you're overstating it. For LAN traffic, it's usually 5-8ms last time I checked on my servers.

You've basically described Firebase and its archetype of database.

That not what we're talking about though, we're talking about aggregating the the result of a subselect to reduce the throughput of a SQL query.

I'm just pointing out it doesn't achieve that.

It's not subjective, it's.objective.

This solution for tuples is objectively worse in every way, throughout, network bandwidth, code complexity, maintainability, error likeliness.

You're just clearly someone who can't admit when they're wrong.

> it's.objective.

Prove it.

> You're just clearly someone who can't admit when they're wrong

You don't have a good technical argument so you jump to ad-hominem's?

They've presented plenty of drawbacks, which you've dismissed as "it's not that bad", while not presenting any benefit.

I've presented the bandwidth vs. memory and CPU trade-off, was that not obvious? Not to mention reduced network round trips, and less overhead on transaction management.

If the biggest issue in my product is JSON deser, I'd be a happy camper.

Bandwidth and memory are probably both worse, JSON adds overhead. Round trip latency only happens if you wait for the results of one query to send the other.

>You're just clearly someone who can't admit when they're wrong.

I suggest avoiding statements like this. Yes they help vent your frustrations but they destroy the otherwise constructive and interesting debate the two of you were having.

> No, you can't use 'negigibly' worse as a defence

Absolutely you can when I can absolutely guarantee you that you’ve written worse performing queries in the past that caused more cpu issues than the overhead of working with JSONB.

Reply on news.ycombinator.com