I’m not very impressed with this work. A DSL for query transformation rules has been tried in the past - all the way back to EXODUS[1] - but there are so many complexities to deal with that it is better to write your rules in a full programming language.
They don’t explicitly talk about relational algebra, which means that they are still thinking they can do their transformations on the SQL AST. Which - as I discovered around 1999, writing my 3rd SQL parser and 2nd optimizer - is not going to work because SQL’s scoping rules make everything too brittle. Julian [1] http://pages.cs.wisc.edu/~dewitt/includes/queryopt/sigmod87.pdf > On Nov 9, 2018, at 7:16 AM, Michael Mior <[email protected]> wrote: > > They're not using Calcite. Their code base is in Go and they wrote their > own in Go. If you read the blog post, they describe a DSL they built for > expressing optimizer rules which is kind of nice although not terribly > different from what we're doing with Calcite. > > -- > Michael Mior > [email protected] > > > Le ven. 9 nov. 2018 à 08:00, Stamatis Zampetakis <[email protected]> a > écrit : > >> Thanks for sharing this Michael! >> >> I had a look on their blog post but I didn't notice something really novel. >> It gives me the impression that they re-implemented a Volcano-style >> optimizer like the one of Calcite. >> >> Out of curiosity, are they using Calcite, or they really built everything >> from scratch? >> >> Best, >> Stamatis >> >> Στις Παρ, 9 Νοε 2018 στις 2:55 π.μ., ο/η Michael Mior <[email protected]> >> έγραψε: >> >>> The folks from Cockroch Labs just shared an interesting blog post on the >>> development of their optimizer. Could be some interesting lessons in >> their >>> code base. >>> >>> https://www.cockroachlabs.com/blog/building-cost-based-sql-optimizer/ >>> >>> >>> -- >>> Michael Mior >>> [email protected] >>> >>
