fuy

FWIW, I think they should've been much more open in their announcement and credited original teams instead of selling this as some kind of almost-autonomous Claude project.

"We took existing system we helped to implement at Meta and changed it a bit" doesn't sound as cool as "Redesigning source control at Anthropic", but seems to be closer to truth?

not necessarily, no. With SSDs you get much better IOPS for cold data, and many datasets fit in RAM. So a lot of (OLTP/HTAP) workloads can become CPU-bound due to sorting/hashing - bread and butter of joins.

yes, if you control the clients and do client-side pooling.

The book is a companion to Machine Learning Systemshttps://mlsyscourse.org/ CMU course.

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.

claude code easily uses 10+GB in single session :) 1Gb sounds very efficient by comparison

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.

sorry about that, I appreciate the reminder. Sometimes it's hard to engage in conversations with obvious bots/bad actors in good faith.

[flagged]

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.

isn't this template supposed to mean that all the previous considerations are now obsolete?

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.

perf and look at stack traces (or off-cpu events for waits/locks). also, ebpf

Hey Tanel - I wanted to thank you for that blog post and psn tool - it recently helped me in a tricky performance investigation.

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.

isolation levels, that is!

Top 5% overall or top 5% of dev jobs? Former sure, latter might be not? I live in Prague, and there are definitely multiple companies that pay more than 90k to middle positions. especially if it's before taxes.

what about npgsql? it's pretty much official and is developed by Microsoft people

And also these old C hands don't seem to get paid (significantly) more than a regular web-dev who doesn't care about hardware, memory, performance etc. Go figure.

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.

Aurora is using native Postgres planner, I believe, probably with some minor enhancements.

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.

and doesn't scale well. Meaning using it can take your Postgres server down way before regular SQL workload would.