Postgresql中执行计划的合并连接

作者：瀚高PG实验室 （Highgo PG Lab）- z
#Merge Join
通常情况下，散列连接的效果比合并连接好，但如果源数据上有索引，或者结果已经被排过序，在执行排序合并连接时，就不需要排序了，这时合并连接的性能会优于散列连接。
下面示例中，people的id字段和dept01的depto字段都有索引，且从索引扫描的数据已经排好序，可以直接走Merge Join：

highgo=# explain select people.id from people,dept01 where people.id=dept01.deptno;
                                           QUERY PLAN
-------------------------------------------------------------------------------------------------
 Merge Join  (cost=0.86..64873.59 rows=1048576 width=4)
   Merge Cond: (people.id = dept01.deptno)
   ->  Index Only Scan using people_pkey on people  (cost=0.44..303935.44 rows=10000000 width=4)
   ->  Index Only Scan using idx_deptno on dept01  (cost=0.42..51764.54 rows=1048576 width=2)
(4 行记录)

删除dept01上的索引，会发现执行计划中先对dept01排序后在走Merge Join，示例如下：

highgo=# explain select people.id from people,dept01 where people.id=dept01.deptno;
                                           QUERY PLAN
-------------------------------------------------------------------------------------------------
 Merge Join  (cost=136112.80..154464.29 rows=1048576 width=4)
   Merge Cond: (people.id = dept01.deptno)
   ->  Index Only Scan using people_pkey on people  (cost=0.44..303935.44 rows=10000000 width=4)
   ->  Materialize  (cost=136112.36..141355.24 rows=1048576 width=2)
         ->  Sort  (cost=136112.36..138733.80 rows=1048576 width=2)
               Sort Key: dept01.deptno
               ->  Seq Scan on dept01  (cost=0.00..16918.76 rows=1048576 width=2)
(7 行记录)

上面执行计划中，可看到“Sort Key: dept01.deptno”，这就是对表dept01的id字段进行排序。