展望 Postgres 19：查询提示
好吧，世界正式完了。《捉鬼敢死队》中的 Peter Venkman 一直是对的，我们很快将体验到"人祭、猫狗同居、大恐慌！"大家收工吧，我们有过一段好日子。Postgres 19 的功能冻结包含了 一个许多人声称永远见不到天日的功能：查询提示。我想"永远别说永远"确实是条好建议。
好吧，严格来说它们不叫"提示"。Postgres 社区绝不会那么肤浅。相反，Postgres 19 引入了两个新的 contrib 模块：pg_plan_advice 和 pg_stash_advice。这叫"计划建议"，明白了吧。完全不同的东西。
如此重要的事件值得我们多花点篇幅来介绍。让我们从 Postgres 历史上持续时间最长的争论之一开始说起。
"永不"的简史
Postgres 社区对查询提示的立场，可以说是——坚定。关于此事的官方维基页面直言不讳：
"我们对以其他数据库常见的方式实现提示不感兴趣。基于'因为它们有'的提案将不受欢迎。"
说得没错。维基还列出了提示有问题的六个充分理由：
- 它们造成维护噩梦。
- 它们会在升级时失效。
- 它们抑制了根因分析。
- 它们扩展性差。
- 优化器通常比你想象的要聪明。
- 它们实际上阻碍了计划器的改进，因为用户不再报告 bug。
事实上，多年来讨论到此为止。Postgres 不做提示。去修你的统计信息吧。下一个话题。
但在幕后，这场争论从未真正平息。早在 2010 年底，著名的帖子在 pgsql-performance 邮件列表上爆发，持续争论了几个月。它开始时只是对慢速 COUNT(*) 查询的抱怨，然后拐到了与 Oracle 的对比，不知怎么就演变成了一场关于 Postgres 是否需要提示的全面存在主义危机。
Robert Haas 率先发难：
"我认为说我们不需要提示是愚蠢的。我们需要提示，至少我们中的许多人需要。我们只是希望它们真的能用，而不是一团糟。"
他进一步认为 Postgres 需要为 DBA 提供应对边缘情况的逃生舱：
"我们应该愿意为那些人提供一种方式，让他们在遇到 0.1% 无法用现有方法修复的查询时，不至于被炒鱿鱼。"
（本文翻译自 pgedge.com 原文）
