加入子查询结果性能
问题描述：
我期待我的优化SQL查询，并想知道，在优化性能方面，如果加入子查询结果性能
SELECT A.this, B.another FROM A
JOIN B
ON A.this = B.that
WHERE B.another > 6
AND A.something < 3;
优于：
SELECT A.this, B.another
FROM (SELECT this FROM A WHERE A.something < 3) AS A
JOIN (SELECT another FROM B WHERE B.another > 6) AS B
ON A.this = B.that;
答
这两个查询运行时相同。尝试运行以explain analyze开头的两个查询，并且应该得到完全相同的查询计划。
简而言之，Postgres将解析查询并提出一个查询树。
它会重新写查询树在适当的时候，以去除多余的东西，如一个1 = 1 where子句，更换小IN()条款或等值使用ANY，或者，你的情况，你的崩溃两个子查询到父查询。它会这样做的原因是，它基本上将它们视为select (select ...)，而内部选择不受聚合，组合或限制子句的限制。
只有这样，它才会花费一些时间分析查询树本身，以搜索它认为最佳的查询计划。最后执行查询计划以返回您要求的行。
对于你要检查出性能提示Postgres的手册中的血淋淋的细节，还有explain和explain analyze语法：
- http://www.postgresql.org/docs/current/static/sql-explain.html
- http://www.postgresql.org/docs/current/static/performance-tips.html
- http://www.postgresql.org/docs/current/static/planner-stats-details.html
- http://www.postgresql.org/docs/current/static/geqo.html
- https://wiki.postgresql.org/wiki/Performance_Optimization
还要注意Postgres的性能邮件列表，它的档案，你会发现这里：
学习他们是非常值得的，在这个意义上，这样做会给你对引擎盖下发生的事情有很多见解。特别关注Tom Lane编写的消息 - 他偶尔会对查询重写器和规划器中发生的事情进行第一手的说明。
Postgres有一个非常聪明的优化器，所以我不认为它实现了子查询。换句话说，这两个版本应该有类似的表现。但是，你应该看看查询计划。 – 2014-12-02 13:28:08
我认为这种优化最好留给数据库，并且使用第一个查询的标准语法给予优化器最大的范围，但我不是DBA。我会很乐意听到关于这方面的更多消息。 – Resource 2014-12-02 13:28:34
当你尝试这两种方法时，结果如何？这是唯一真正知道的方法。 – Flimzy 2014-12-02 13:35:57