Your argument applies to literally every database. A sequential scan can be way faster then a using a index. That is a optimization that can under the right circumstances result in a great benchmark score, but a bad experience for some customers but great for others.

The idea that benchmark optimizations are all bad, is the flawed argument. A benchmark is nothing else but a pattern. You can indeed over optimize like having a LLM recalculate values in advance but if those optimizations also work on non-benchmark SQL prompts, ... That brings us back to the original point.

There is nothing wrong with having LLMs try and find spot to optimize, as long as your test pattern is not limited to a singular set of data. The reality is, there is actually a lot of meat on the bones in a lot of databases, because it was not physically possible to try and run 100 or 1000s of permutations on query/data patterns. That has now changed.

A discussion like this kind of reminds me driver optimizations for GPUs. The idea of only targeting the average, is what GPU's did like 15+ years ago. The issue was when they optimization was purely done to only benefit the benchmark (like preloading in dbs).

Where optimizations that made for faster benchmark results, also applied to games getting more FPS. This was such a hot topic years ago. Now nobody blinks a eye anymore when we even see game on game optimizations.

I can even argue the other way...

If a client has a database with a know pattern, and that client can enjoy a 10x performance increase because of that pattern optimization. And it does not reduce performance for others. Maybe that same optimization will trigger on some other client, who was not even the target.

What if your database has optimization that makes Wordpress work way faster. Thing is ... this type of targeted optimization already happens everywhere. I find it just odd that this is a discussion regarding databases.

Pre rendering data for a benchmark is indeed cheating, because that does not help clients, its misleading. But being able to show, "hey, we make X popular software faster then (example) postgres". The client are those that gain. And with LLMs that is now possible to do, without the cost the limited this in the past.

Yes, I am aware that databases do that. But my point is that databases are conservative with what kind of optimizations they do, because the space of possible queries are infinite, and they want to have a guaranteed bound on what the worst case behavior is.

Big OLAP vendors like Snowflake do have the workloads of their customers, but you cannot just evaluate your optimizations on all workloads because its too expensive. You will only notice after deployment, when the customer calls you to complain. Or worse, they won't even consider you, because your novel workloads are too slow.

My point is not that specialized implementations can't deliver big performance gains, but that deciding when to use optimizations that have downsides reliably is very hard. Even for a classical problem, well isolated problem, like join-order optimization, even if you have perfect cardinality estimates (which you don't), its still NP-hard, and still, even optimizers that are considered advanced, will choke.

Anything engine/implementation specific is far worse, with smaller gains and much bigger downsides, which every systems routinely screws up because its just really difficult to decide when to use what.