tpetry

Honestly, if the database is not able to be run with a variety of queries other than the one used by ClickBench then don't submit it to the benchmark. Every other database in their list can run anything you throw at it. Hiding behind messaging that it was an early 0.4 build that can't do everything is ... weird! Just don't submit it to ClickBench if it is not usable by the world yet.

I hope they don't allow pgrust in again until the project matured. Otherwise the benchmark will be useless as it gets flooded by many projects that can run ClickBench fast but have questionable support for everything else.

The article says that other models are better at performance or cost. But whaz is not mentioned? Models that are _better_. From my testing, most models are much worse. And if you do an analysis on quality/performance/cost no one is beating Jev. Heck, no one is beating it at performance and cost at the same time.

There‘s a lot of hype with many releasing their decision models the past weeks. But all are worse. So maybe the years they spent in stealth is something you cant replicate in two weeks?

And the 'better' ones are slower and cost more for a tiny bit more accuracy. Its hard to sell that as being better when speed and price have been JEVs main selling points.

Oh I dont disagree that it does replace some jobs. Why use junior developers when AI generates the same quality?

Just that comparing LLM to a compiler is nonsense. Because one is deterministic and the more using it, the better the quality will get.

Its a false premise so often repeated. I am really tired. Compilers are ruleset: If you pass it one statement it'll produce the same output all the time. Its easy to verify it works. And if enough people have used it before and found no problems, there probably aren't many. Spoiler: People always find niche bugs.

But an LLM will generate you two completely different things today and tomorrow. Heck, even if you stash its changes and redo the same prompt.

They are NOT comparable at all.

Did you even read the article? They show that a perfect index for their query didnt help because Skip Scan is currently not used for DISTINCT queries.

Its running for 15 minutes and then must shut down for a long time to cool down. Thats exactly why those "science-fluencers" said its a dumb idea. This is far away from proving that its a viable idea.

Sam is always shitting on others. For years he has been screaming how bad PostgreSQL is compared to MySQL. Until getting silent about this topic for a few months and then launching PostgreSQL support. Seems he had to realize than the market for PostgreSQL is too big to ignore.

And there is no single company developing. Its a healthy mix of engineers from many companies. A perfect model to prevent this issue here of being aquihired.

The question is more what this really solves. They said they built all this because DNS propagation was too slow. But secondary dns servers by e.g. your isp will still have old records when you change something. So what did they earn? Every is correct within their network pretty fast. But for a normal user there isnt any difference because 8.8.8.8 or 1.1.1.1 still cache old records?

Sometimes similar articles are merged into one. Including the comments.

You immply that a testcase exists for every weird edge case. Especially filesystem and concurrency is things you can barely build test cases for.

Even a 100% test coversge is far away from verifying all behaviour.

These are for type-checking. Transpiling takes barely any time.