HN user

fuy

125 karma

Senior developer at Veeam. Interested in databases, performance engineering, books and music. shelemin@gmail.com

Posts2
Comments95
View on HN

There's been many examples of societies where killing or abusing people was legal etc. Law is not math, it can be (and often is) wrong; in many cases a law is just a way for ruling class to make money/keep power etc. It's completely OK to protest laws, and it may be completely reasonable to consider someone a criminal even if they haven't broken any laws.

almost all Spotify playlists/radio features are extremely stupid. Radios all repeat the same 2-3 songs per artist, doesn't matter where you start. Classical pieces in radios are always 1-2 minutes long etc etc. It was like before AI though.

CLUSTER command is not the same as index organized tables, it's a one-time "physical sort" operation. New data is not organized until you run CLUSTER again. Index organized tables are maintained automatically by Oracle/SQL Server.

Not saying you're wrong, but solo developers building (relatively) greenfield projects are the best bet for increased AI productivity.

Solo dev projects are usually reasonably sized (< million LOC), style is more uniform, there's fewer silos etc. etc.

Good studies look at a broader picture.

.NET 10 8 months ago

It's web in a (limited) sense that there's probably a web frontend somewhere, but this "somewhere" is usually pretty far away from where most of the code is developed.

Most of the backend logic is not related to serving data for the browsers, it's doing actual backend stuff - communicating to databases, APIs, etc.

Is Google search backend a web app? I think it's really stretching the term.

Looking at first optimization, I wonder if double-checking after acquiring exclusive lock brings any performance benefits. The whole premise is that cache access is read-heavy, so not acquiring exclusive locks for reads eliminates by far the biggest problem.

Rare (I presume) cases of overlapping updates from different threads (considering updates themselves are also infrequent) don't seem like a big deal compared to lock elimination. Would be interesting to see benchmark numbers for those optimizations separately.

Had similar situation a few years before - switched a (now) billion revenue product from Read Committed to Read Committed Snapshot with huge improvements in performance. One thing to be aware when doing this - it will break all code that rely on blocking reads (e.g. select with exists). These need to be rewritten using explicit locks or some other methods.

Thomas Neumann and Alfons Kemper papers can hardly be called "home-grown", their stuff has been implemented in multiple industrial systems. Postgres optimizer, though, is very bad even with simple correlated subqueries, let alone "arbitrary", so it'd be useful to have at least some version of unnesting.

I love and use Postgres daily for many years, but:

Performance monitoring is pretty much absent, all you have is pg_stat_statements and friends. So for any serious scale you need 3d party solution (or you're writing your own) straight away.

HA is complicated. Patroni is the best option now, but it's quite far from experience SQL Server or Oracle provide.

Optimizer is still quite a bit simpler than in SQL server/Oracle. One big thing that is missing for me is "adaptive" query processing (there's AQP extension, but it's not a part of distribution). Even basic adaptive features help a lot when optimizer is doing stupid things (I'm not gonna bring up query hints here :))

Are you saying medieval Germany was richer than present-day Germany or USA? That's of course not true. And it's also not clear why you call it a survivorship bias - these villages were probably above-the-median in their days, but it's not some singular building like Pyramids that is not representative of overall building of that era/territory. It was just how the houses were built there and then.

One other thing about JIT that I feel is pretty crazy is that the generated code is not cached. I mean it's the most expensive part of the query execution a lot of the time, how come it's not cached? I couldn't find good reasons for this looking through Postgres mailing lists discussion around JIT.

Disabling JIT is the way to go for OLTP workloads.

Or it could work in a way that the Planner has access to data about previous runs of each query, and it can use this data to change plans that were proven bad during execution. This way, the first execution would be slow, but Planner could self-learn and better next time. SQL Server has a bunch of similar features in its query optimizer https://learn.microsoft.com/en-us/sql/relational-databases/p....

I'm not sure Postgres has infrastructure to do that, though, because it doesn't have shared plan cache, for example.

+. And then you have to figure everything one more time when you decide to move to (or to add support for) Azure/GCP.

The common sentiment on HN I'd say is the opposite: ORM's are needed for junior devs who didn't have time to learn SQL properly. After NoSQL hype died out (around 5 years ago), the HN attitude towards both ORM's and using NoSQL instead of relational dbs has been mostly negative for sure.

This basis is our limited data set: we have only 1 example of human level intelligence, so it's natural to assume there's something unique, or at least significant about the way it works.

it's probably been mentioned before, but there are customers that require IPv6 (like some US gov agencies and others), so for a lot of B2B/enterprise software companies it actually makes sense to support ipv6. And it's technically interesting, so why not! (I've been there, and it was fun)