dlurton

Also, the PartiQL compiler makes heavy use of closures, each of which becomes a class, so the first time a query executes the JVM has to load a few dozen classes--this probably explains the 86ms more than a lack of JIT optimizations alone.

ORDER BY is still in the works: https://github.com/partiql/partiql-lang-kotlin/issues/47

One big difference is native support for nested data that's built right into the syntax of the language. Most other SQL implementations allow support for nested data through functions which have non-intuitive syntax.

It would be possible to integrate parquet data with PartiQL.

Here is an example of integrating PartiQL with CSV files. https://github.com/partiql/partiql-lang-kotlin/blob/master/e.... Integrating with Parquet would of course be more complex then that.

This is on the JVM so the JIT's optimizations probably haven't kicked in yet.