Very nice write up enumerating all the stages of SQL query execution. Interesting even if you don’t care about the DoIt database specifically.

Man, this title tripped me up for a minute because I pronounce it with the letters like Ess-Queue-Ell

So the "A" in "A ess-queue-ell" engine felt like it should have been an "An" until I realized it was meant to be pronounced like "sequel"

This is a great write up about a pull-style volcano SQL engine.

The IR I've used is the Calcite implementation, this looks very concept adjacent enough that it makes sense on the first read.

> tmp2/test-branch> explain plan select count() from xy join uv on x = u;

One of the helpful things we did was to build a graphviz dot export for the explains plans, which saved us days and years of work when trying to explain an optimization problem between the physical and logical layers.

My version would end up displayed as SVG like this

https://web.archive.org/web/20190724161156/http://people.apa...

But the calcite logical plans also have that dot export modes.

https://issues.apache.org/jira/browse/CALCITE-4197

I recommend anyone who works with databases to write a simple engine. It's a lot simpler than you may think and it's a great exercise. If using python, sqlglot (https://github.com/tobymao/sqlglot) let's you skip all the parsing and it even does some simple optimizations. From the parsed query tree it's pretty straightforward to build a logical plan and execute that. You can even use python's builtin ast module to convert sql expressions into python ones (so no need for a custom interpreter!)

Using dolthub's go-mysql-server for Grafana's upcoming SQL expressions feature (private preview in Grafana 12, but in the OSS version with a feature toggle).

GMS lets you provide your own table and database implementations, so we use GMS to perform SQL queries against Grafana's dataframes - so users can join or manipulate different data source queires, but we don't have to insert the data into SQL to do this thanks to GMS.