postgres-xl left join 执行时间过长

Posted 2023-05-08

【中文标题】postgres-xl left join 执行时间过长

【英文标题】：postgres-xl left join takes too long to execute

【发布时间】：2018-07-10 13:18:01

【问题描述】：

Postgres-XL 9.5r1.6 由一个 gtm、一个协调器和两个数据节点组成。

三个表a、b和c实现了多对多关系：

create table a(id int, name text, uid int) distribute by hash(uid);
create table b(id int, name text, uid int) distribute by hash(uid);
create table c(id int, aname text, bname text, uid int) distribute by hash(uid);

当在coordinator上运行以下查询时，它花费了20000毫秒的莫名其妙的时间！但在任一 datanodes 上，执行时间几乎不会超过 20 毫秒。

select a.name, b.name

from 
       a left join c
       on a.name=c.aname

          left join b
          on c.bname=b.name
where
       a.name='cf82c96b77b8aa5277da6d55c4e4e66e';

向协调员解释计划：

Remote Subquery Scan on all (dn_1,dn_2)  (cost=8.33..17.78 rows=1 width=66)


 ->  Nested Loop Left Join  (cost=8.33..17.78 rows=1 width=66)
         Join Filter: ((a.name)::text = (c.aname)::text)
         ->  Remote Subquery Scan on all (dn_1,dn_2)  (cost=100.15..108.21 rows=1 width=33)
               Distribute results by H: name
               ->  Index Only Scan using code_idx on a  (cost=0.15..8.17 rows=1 width=33)
                     Index Cond: (name = 'cf82c96b77b8aa5277da6d55c4e4e66e'::text)
         ->  Materialize  (cost=108.18..109.72 rows=1 width=115)
               ->  Remote Subquery Scan on all (dn_1,dn_2)  (cost=108.18..109.72 rows=1 width=115)
                     Distribute results by H: aname
                     ->  Hash Right Join  (cost=8.18..9.60 rows=1 width=115)
                           Hash Cond: ((b.name)::text = (c.bname)::text)
                           ->  Remote Subquery Scan on all (dn_1,dn_2)  (cost=100.00..102.44 rows=30 width=33)
                                 Distribute results by H: name
                                 ->  Seq Scan on b  (cost=0.00..1.30 rows=30 width=33)
                           ->  Hash  (cost=108.41..108.41 rows=1 width=244)
                                 ->  Remote Subquery Scan on all (dn_1,dn_2)  (cost=100.15..108.41 rows=1 width=244)
                                       Distribute results by H: bname
                                       ->  Index Only Scan using code_idxcfc on c  (cost=0.15..8.17 rows=1 width=244)
                                             Index Cond: (aname = 'cf82c96b77b8aa5277da6d55c4e4e66e'::text)

其他人已经遇到了这个问题并问了here，但没有答案或提示。我只是希望这次问题能得到一些见解。

ps：我尝试填充三个表，使a 和b 中的相关行构成表c 仅来自同一个数据节点。但执行时间没有改善。 另一点值得注意的是，当where 子句（a.name='cf82c96b77b8aa5277da6d55c4e4e66e'）中的条件始终为假时，执行时间会下降到不到几毫秒。

【参考方案1】：

对于这个查询：

select a.name, b.name
from a left join
     c
     on a.name = c.aname left join
     b
     on c.bname = b.name
where a.name = 'cf82c96b77b8aa5277da6d55c4e4e66e';

您希望在a(name)、b(name) 和c(name) 上建立索引。您的分区对这个查询没有帮助，只有在表很大时才应该保留它们。

【讨论】：

实际上我已经尝试过构建索引，但对执行时间没有明显影响，而且表确实增长很快（社交网络应用程序数据库），因此集群是必不可少的方法。

【参考方案2】：

这是由于嵌套循环造成的，请将其设置为 false。 XL 会使用 hash join 快速返回结果