странный результат запроса - другой номер выражения «in clause» в greenplum 5.0 - PullRequest
0 голосов
/ 31 октября 2019

Я замечаю странный результат при использовании 'in clause' в greenplum 5.0.

когда номер выражения «в предложении» <= 25, запрос линейно замедляется (как и ожидалось), но когда число выражения> 25, запрос, очевидно, быстрее (чем число = 25). почему это происходит?

Я объясняю запрос, запускаю с использованием нового / устаревшего оптимизатора, вывод такой же. вот запрос 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,8 с ~ 0,9 с

объяснение:

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

объяснение, анализ:

Gather Motion 8:1  (slice1; segments: 8)  (cost=0.00..481.53 rows=2003 width=1064)
  Rows out:  0 rows at destination with 52 ms to end, start offset by 0.477 ms.
  ->  Table Scan on table1 (cost=0.00..475.63 rows=251 width=1064)
        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,26}'::text[])
        Rows out:  0 rows (seg0) with 51 ms to end, start offset by -358627 ms.
Slice statistics:
  (slice0)    Executor memory: 437K bytes.
  (slice1)    Executor memory: 259K bytes avg x 8 workers, 281K bytes max (seg7).
Statement statistics:
  Memory used: 262144K bytes
Settings:  optimizer=on
Optimizer status: PQO version 2.42.0
Total runtime: 53.107 ms

запрос 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,2 с ~ 1,5 с

объяснение:

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

объяснение anaylze:

Gather Motion 8:1  (slice1; segments: 8)  (cost=0.00..481.53 rows=2003 width=1064)
  Rows out:  0 rows at destination with 60 ms to end, start offset by 0.517 ms.
  ->  Table Scan on table1 (cost=0.00..475.63 rows=251 width=1064)
        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[])
        Rows out:  0 rows (seg0) with 59 ms to end, start offset by -155783 ms.
Slice statistics:
  (slice0)    Executor memory: 437K bytes.
  (slice1)    Executor memory: 191K bytes avg x 8 workers, 191K bytes max (seg0).
Statement statistics:
  Memory used: 262144K bytes
Settings:  optimizer=on
Optimizer status: PQO version 2.42.0
Total runtime: 60.584 ms

gp работает в 3 виртуальных машин, 1 мастер и 2 сегмента, каждый сегмент имеет 4 каталога данных.

table1 имеет 500 000 строк с 50 столбцами, первичный ключ и ключ распределения - это еще один столбец в uuid. column1 не является ключом распространения или первичным ключом, это просто ключ природы.

1 Ответ

0 голосов
/ 31 октября 2019

вы можете запустить объяснить анализ, чтобы увидеть, на что именно план потратил время. Поделитесь здесь.

...