4 ms·
Yeah that's basically what was discussed here: https://lobste.rs/s/xz6fwz/unix_find_expressions_compiled_bytecode https://lobste.rs/s/xz6fwz/unix_find_expressio
by chubot 10mo ago
Yeah that's basically what was discussed here: https://lobste.rs/s/xz6fwz/unix_find_expressions_compiled_bytecode https://lobste.rs/s/xz6fwz/unix_find_expressions_compiled_by...
And then I pointed to this article on databases: https://notes.eatonphil.com/2023-09-21-how-do-databases-execute-expressions.html https://notes.eatonphil.com/2023-09-21-how-do-databases-exec...
Even MySQL, Duck DB, and Cockroach DB apparently use tree-walking to evaluate expressions, not bytecode!
Probably for the same reason - many parts are dominated by I/O, so the work on optimization goes elsewhere
And MySQL is a super-mature codebase
- drob518 10mo agoI was just reading a paper about compiling SQL queries (actually about a fast compilation technique that allows for full compilation to machine code that is suitable for SQL and WASM): https://dl.acm.org/doi/pdf/10.1145/3485513 https://dl.acm.org/doi/pdf/10.1145/3485513 Sounds like many DBs do some level of compilation for complex queries. I suspect this is because SQL has primitives that actually compute things (e.g. aggregations, sorts, etc.). But find does basically none of that. Find is completely IO-bound.
- hxtk 10mo agoVirtually all databases compile queries in one way or another, but they vary in the nature of their approaches. SQLite for example uses bytecode, while Postgres and MySQL both compile it to a computation tree which basically takes the query AST and then substitutes in different table/index operations according to the query planner. SQLite talks about the reasons for each variation here: https://sqlite.org/whybytecode.html https://sqlite.org/whybytecode.html
- drob518 10mo agoThanks for the reference.