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.
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.
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.
"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.