Hacker News new | ask | show | jobs
by benzayb 509 days ago
"make sql as fast as possible" is a misnomer.

you cannot make a language fast, only its underlying implementation (i.e the specific dbms).

and this is the error I see 90% of the time. there is a confusion between conceptual (model) vs implementation concerns.

the problem with SQL the language is its conceptual foundations -- that it is not currently relational and yet it is used as the language of "relational" DBMSes in the market.

1 comments

It says “making sql go as fast as possible”, referring to the talks about optimizers.
To quote:

"The talks in this series will present ideas on either (1) making SQL go as fast as possible or (2) replacing SQL with something better."

How were you able to infer that the existence of the word "go" in that phrase refers to optimizers?

And 2nd idea/proposal of "replacing SQL with something better" really implies that they are talking about the language and not the optimizer.

In any case, if they really meant "optimizer" then their phrasing is very vague and imprecise; if they are talking about the "optimizer" -- then which specific optimizer? They have failed to mention that too.

Correct. I think the parent commenter is confusing a language's concrete syntax with its abstract syntax. At the end of the day, the ease (or lack there of) of translating an AST into performant executing code is highly correlated with the potential variance of those ASTs.

The more higher-level expressions your languages supports, the more work its compiler (whether targeting physical or virtual hardware) must do to translate those ASTs into "machine" code and the higher the variance of that code during its execution workload.

It's even more work when that language's expressions are declarative instead of imperative.

When a DBMS that claims it is relational and yet it supports SQL's "features" that departs from the relational model, then that DBMS is not relational.

If a DBMS is "slow" or "fast", that is not because of SQL -- it is because of the specific implementation decisions that the makers of that DBMS took.

And that has nothing to do with what you just said.