优化器提示讨论
来自 PostgreSQL 维基
跳转到导航跳转到搜索优化器和查询提示讨论
多年来，许多人要求 PostgreSQL 项目实现“优化器提示”或“查询提示”，就像他们在其他 RDBMS（如 Oracle 和 MySQL）中实现的那样。社区目前官方立场如下
我们对以其他数据库中常见的模式实现提示不感兴趣。基于“因为他们有”的提议将不受欢迎。如果您有想法可以避免在其他提示系统中观察到的问题，这可能有助于进行有价值的讨论。
现有提示系统的问题
- 应用程序代码可维护性差：查询中的提示需要大量的重构。
- 升级干扰：如今有帮助的提示在升级后会变成反性能。
- 鼓励不良的 DBA 习惯：在解决真正问题之前，用提示来敷衍了事。
- 无法随着数据大小扩展：当表很小时正确的提示，在表变大时很可能就会错误。
- 无法真正提高查询性能：大多数情况下，优化器实际上是正确的。
- 干扰查询计划器改进：使用提示的人很少向项目报告查询问题。
现有提示系统带来的益处
- “一次性”问题，例如年度或一次性报告，维护性不是问题
- 能够详细“测试”各种执行路径，并查看优化器是如何工作的（或不工作）
- 优化器故障
- 实现失败（已知问题）
- 理论失败（估计限制、n^2 相关性问题）
可用于查询排查的机制
数据库中存在一些现有控制，它们的影响类似于人们期望提示能实现的效果。请查看 在 PostgreSQL 中使用提示，其中列出了一些控制措施。
