奇怪的查询性能结果-greenplum 5.0中'in子句'的不同表达式编号

Question

我在greenplum 5.0中使用'in子句'时注意到奇怪的结果。

当'in子句中的表达式数量<= 25时，查询线性降低（如预期的那样），但是当表达式数量> 25时，查询明显更快（比number = 25）。为什么会这样？

i解释查询，使用新的/旧版优化器运行，输出相同。这是查询sql并解释结果。

查询1-26表达式编号

sql：

select * from table1 
where column1 in ('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','25','26')

查询时间：0.8s〜0.9s

解释：

Gather Motion 8:1  (slice1; segments: 8)  (cost=0.00..481.59 rows=2021 width=1069)
  ->  Table Scan on table1 (cost=0.00..475.60 rows=253 width=1069)
        Filter: column1 = ANY ('{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25}'::text[])
Settings:  optimizer=on
Optimizer status: PQO version 2.42.0

查询2-25表达式编号

sql：

select * from table1 
where column1 in ('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','25')

查询时间：1.2s〜1.5s

解释：

Gather Motion 8:1  (slice1; segments: 8)  (cost=0.00..481.59 rows=2021 width=1069)
  ->  Table Scan on table1 (cost=0.00..475.60 rows=253 width=1069)
        Filter: column1 = ANY ('{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25}'::text[])
Settings:  optimizer=on
Optimizer status: PQO version 2.42.0

gp在3个vm，1个master和2个段中运行，每个段都有4个数据目录。

table1具有500,000行，其中包含50列，主键和分配键在uuid中是另一列。 column1不是分发键或主键，而只是自然键之一。

Answer 1

您可以运行解释分析以查看计划花了多少时间。在这里分享。