主要观点：

• 如今数据库查询引擎需考虑磁盘延迟降低，解释器开销成为问题，向量化可解决 OLAP 类查询的瓶颈，而 OLTP 类查询需将查询编译为原生代码以优化。
• 编译查询存在困难，如难以确定哪些查询值得编译、存在性能悬崖等，所以许多数据库仍选择向量化解释器。
• 浏览器在执行 JavaScript/wasm 时也面临编译时和运行时的权衡，其架构类似有解释器、基线编译器和优化编译器。
• 基线编译器后端未被商品化，成功项目多使用自定义后端，编写基线编译器可能不比写向量化解释器难很多。
• 可通过复制和补丁、将查询编译为 wasm、生成免费的解释器或编译器等方式减少编写基线编译器的工作量。

关键信息：

• 不同类型查询（OLAP、OLTP）的特点及优化方法。
• 编译查询的困难及各种 workaround。
• 浏览器执行 JavaScript/wasm 的架构及相关研究。
• 基线编译器相关的开源库及项目情况。
• 减少编写基线编译器工作量的多种方式及各自特点。

重要细节：

• 对于 OLTP 类查询，如 SQLServer、SingleStore、Redshift、Oracle 等数据库将查询编译为原生代码。
• 编译查询时用户需手动指定或估计是否值得编译，数据库可缓存编译结果但仍存在问题。
• 浏览器中不同浏览器在切换到编译代码的方式及优化程度上有所不同。
• 开源 jit 编译器库多有自定义后端，如 yjit 在 Ruby 中取得成功。
• 复制和补丁方式依赖 llvm 特定部分且可能存在不足。
• 将查询编译为 wasm 存在诸多限制，如依赖 V8 等。
• 生成免费的解释器或编译器的相关项目及特点，如 SpiderMonkey、Inkfuse 等。