On Tue, Sep 14, 2021 at 4:16 PM FWS Neil <neil@fairwindsoft.com> wrote:
> What people hate about SQL is that the programmer has to optimize SQL to get acceptable performance.
Oh, no, that's just one thing. :-)
And to be fair, it's a hard problem. We're asking for an optimizer,
written for databases generally, to out-perform an intelligent human
who knows one particular database well. And we don't collect all the
data the optimizer might want, because of the performance or storage
costs to the collection (e.g. keeping accurate record totals by
performing a write operation on every insert).
In my daydreams, I sometimes think that making the query planner more
modular, and perhaps writing it in a higher-level language might be
good. Usually, optimizing for fast performance will beat optimizing
for performance fast. So it's a system you'd want to be able to tune
and improve easily.
> And the optimization is different for every implementation. I think SQL has not hit its stride yet. When the common
$1000server has 1024+ CPUs and 1+TB memory, and SQL implementations have adopted good multithreading architecture with
accessto 1024+ CPU dedicated AI engines, etc. a lot of the crap associated with performant SQL will go away.
Yeah... I don't. When a common server is 1000 times faster, people
will find reasons to do 1000 times as much with it.
> At this point, I think it will be smart to strip out implementation details that have made it into the SQL syntax.
Therewill no longer be a need for it. This will make the SQL language simpler and easier to use, understand, and reason
about.
A clean division between the query and the performance hints seems
like it'd be a big improvement. Rather like moving presentation
details from HTML off into CSS. Again, I don't see them going away,
though.
--
Ray Brinzer