PostgreSQL 是否总是以与 FROM ... JOIN ... ON ... 相同的方式实现 FROM ... WHERE？答案

【问题标题】：Does PostgreSQL always implement FROM ... WHERE in the same way as FROM ... JOIN ... ON ...?PostgreSQL 是否总是以与 FROM ... JOIN ... ON ... 相同的方式实现 FROM ... WHERE？
【发布时间】：2018-12-01 22:14:18
【问题描述】：

在PostgreSQL document，有两个例子：

EXPLAIN SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
                                        QUERY PLAN
------------------------------------------------------------------------------------------
 Hash Join  (cost=230.47..713.98 rows=101 width=488)
   Hash Cond: (t2.unique2 = t1.unique2)
   ->  Seq Scan on tenk2 t2  (cost=0.00..445.00 rows=10000 width=244)
   ->  Hash  (cost=229.20..229.20 rows=101 width=244)
         ->  Bitmap Heap Scan on tenk1 t1  (cost=5.07..229.20 rows=101 width=244)
               Recheck Cond: (unique1 < 100)
               ->  Bitmap Index Scan on tenk1_unique1 
 (cost=0.00..5.04 rows=101 width=0)
                     Index Cond: (unique1 < 100)

和

EXPLAIN SELECT *
FROM tenk1 t1, onek t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
                                        QUERY PLAN
------------------------------------------------------------------------------------------
 Merge Join  (cost=198.11..268.19 rows=10 width=488)
   Merge Cond: (t1.unique2 = t2.unique2)
   ->  Index Scan using tenk1_unique2 on tenk1 t1  (cost=0.29..656.28 rows=101 width=244)
         Filter: (unique1 < 100)
   ->  Sort  (cost=197.83..200.33 rows=1000 width=244)
         Sort Key: t2.unique2
         ->  Seq Scan on onek t2  (cost=0.00..148.00 rows=1000 width=244)

哈希连接和合并连接是实现连接的方法（明确地在 SQL, FROM ... JOIN ... ON ...)。

PostgreSQL 是否以与上述示例相同的方式实现 FROM ... WHERE 从...加入...开启...？它总是这样吗？

一般在 PostgreSQL 中，我想知道什么时候使用 FROM ... JOIN ... ON ... 以及何时使用 ... FROM ... WHERE ...，当两者看起来相同时有效？

谢谢。

我阅读了其他 RDBMS 的一些类似帖子，例如 INNER JOIN ON vs WHERE clause、SQL join: where clause vs. on clause、WHERE Clause vs ON when using JOIN 和 Filtering JOINs: WHERE vs. ON。他们中的大多数人都在谈论

人类可读性，
内连接与外连接，另见In outer join, where does a plain filter condition come from?
FROM ... WHERE ... 将实现 WHERE 选择对 FROM 笛卡尔积的结果，而 FROM ... JOIN ... ON ... 将实现 ON 选择在创建笛卡尔积时。

【问题讨论】：

始终使用正确、明确、标准 JOIN 语法。这是编写JOIN 查询的正确方法。逗号用于 SQL 的最早版本（想想 1980 年代）。从那时起，我们取得了很大进步。
。 .不幸的是，文档中的代码大约每世纪更新一次。 JOIN 更强大，因为它支持不同类型的连接并且方便，因为它允许USING 子句（忘记NATURAL JOIN，这是一个糟糕的构造）。大多数人也发现它更具可读性，因为条件在表引用旁边，所以条件很容易验证。
@Tim, natural join 被认为是不好的，因为它不明确。数据库架构发生变化，您最终可能会在连接的任一侧添加具有相同名称的其他列，从而完全且无声地改变行为。
考虑两个具有初始架构 t1 (a, b, c, d) 和 t2 (a, b, x, y) 的表。随着时间的推移，应用程序开发人员意识到他们希望t2 有一个额外的列，并决定将其命名为c，却没有意识到周围潜伏着一个自然连接。你能猜出在这种情况下会发生什么吗？
自然连接使用同名的列，而不是声明的外键。 rextester.com/TZF86758

标签： sql postgresql join

【解决方案1】：

如果两个查询的含义相同，那么 postgresql 会尝试以相同的方式执行它们。但是，这并不总是有效。这是目标，但并不总是有效，主要是因为规划者没有意识到两者必然相同。您的数据库架构可能存在缺陷，当然查询计划器中可能存在错误或洞察力不足。

将频繁使用的查询重写为执行更好的等效形式是很常见的。（我个人非常喜欢 postgresql 的原因之一是重写后的查询通常比我原来的查询更能表达我的意图。）

您的问题的答案可以概括为“理论上是的，而且在实践中经常是的”。

【讨论】：