托马斯·冯德拉：[补丁想法] `IN` 查询的自适应执行
💡
原文英文，约1400词，阅读约需5分钟。
📝
内容提要
上周我参加了马尔默PUG会议，讨论了IN查询性能问题。元素数量限制了性能，线性搜索和哈希表的选择阈值不够灵活。建议在运行时收集成本数据，以动态调整策略，从而提高查询效率，但需解决测量成本的准确性和平台支持问题。
🎯
关键要点
- 上周参加了马尔默PUG会议，讨论IN查询性能问题。
- 元素数量限制了IN查询的性能，线性搜索和哈希表的选择阈值不够灵活。
- 建议在运行时收集成本数据，以动态调整查询策略，提高查询效率。
- 当前的阈值是硬编码的，可能导致性能不佳的情况。
- 需要考虑比较成本和哈希计算成本来确定更好的阈值。
- 实现过程中需要更新表达式解释器以支持动态策略调整。
- 主要风险在于如何准确测量不同策略的成本。
- 平台支持也是一个风险，需要找到适合不同平台的解决方案。
- 这个补丁可能是一个有趣的稳健性改进。
❓
延伸问答
IN查询性能问题的主要原因是什么？
IN查询性能问题主要是由于元素数量限制了查询效率，线性搜索和哈希表的选择阈值不够灵活。
如何提高IN查询的执行效率？
可以在运行时收集成本数据，以动态调整查询策略，从而提高IN查询的执行效率。
当前IN查询的阈值是如何设定的？
当前的阈值是硬编码的，线性搜索用于最多8个元素的列表，9个及以上元素则使用哈希表。
在实现动态策略调整时面临哪些风险？
主要风险包括如何准确测量不同策略的成本，以及平台支持的问题。
为什么需要更新表达式解释器？
需要更新表达式解释器以支持在执行时动态调整查询策略，而不是仅在查询规划时决定策略。
如何收集IN查询策略的成本数据？
可以通过在运行时测量每种策略的执行时间来收集成本数据，以便调整阈值。
➡️
