为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【概述】 场景 + 问题概述
我有个小白的问题，貌似tiflash是独立的向量化引擎，tidb是火山模型，为什么tidb不直接也改成向量化模型呢。。火山模型的优势是什么呢。。
【背景】 做过哪些操作
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】
【 TiDB 版本】
【附件】 相关日志及监控（https://metricstool.pingcap.com/)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
对向量化执行器不太了解，之前在调研 apache doris时了解过，作为实时数仓，走向量化执行是挺好的。
在TiDB这边，为了改写TiDB某些功能我亲手写过火山模型的实现。
火山模型简单，每个 Operator 可以单独抽象实现、不需要关心其他 Operator 的逻辑。
但是其缺点也比较明显，多次调用next将造成大量的虚函数调用，造成CPU利用率不高。
总之TiDB选择火山模型应该是权衡各种因素做出的决定，期间肯定也是各种验证才有了这种架构。
恩，我就是好奇火山模型在tidb/tiflash的场景的优势是什么，按照我的理解，貌似没什么优势。。。
您好，
首先 TiDB 是有向量化执行的，几乎所有的表达式都有向量化实现：https://pingcap.com/blog/10x-performance-improvement-for-expression-evaluation-made-possible-by-vectorized-execution
关于火山模型 / 向量化的对比取舍，建议您看一下马晓宇老师的这个视频：https://www.bilibili.com/video/BV1dw411o7To（15 分 30 秒），这里面阐述的非常清楚。
恩，看到了。我的意思是为什么不整套引擎都做成向量化，比如crdb，已经废弃了rowexec的逻辑了。虽然rowexec也有batch，也有一些向量化的逻辑。。不过如今都废弃了
我理解：可能投入的资源，成本和时间，达不到预估的目标，然后这样更有把握，更容易达到目标吧！
然后向量化执行肯定需要一定的基础的，未来tidb 可能会往你说的方向走～～ （我觉得是好事）
哦。不过tiflash不是已经做成向量化引模型了吗。。。
面向的方向不一样阿，
一种是行处理，一种是列处理
这个无所谓的，火山在处理行存的时候也并没有什么优势的。。。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。