Greenplum secrets🎩

Секрет 26,ч2. (Я знаю, что ничего не знаю: наводим резкость на small data )
Случился прецедент за гранью моего понимания, и по делу проходит снова справочник без статы:
на проме запрос

select cap_.agreement_rk, vc4_.product_bp_nm
from mart$v as cap_
         join dict_product as vc4_
              on cap_.product_bp_cd = vc4_.product_bp_cd
where cast('2025-11-26' as date) >= cap_.effective_from_dttm
  and cast('2025-11-26' as date) < cap_.effective_to_dttm;

ежедневно отрабатывает в среднем за 1.5 мин, без проблем, как ни странно,
где mart$v - SCD2 вью для отбора последних версий, с идеей которой мы уже знакомы:

select *
from public.foo a
         join (
    select n, max(version_id) version_id from public.foo where version_id between :v_min and :v_max group by 1) c
              using (n, version_id);

dict_product - пересобираемый под запрос тривиальный справочник в 1500 строк ( коды которых уникальны ), по которому стата не собрана, согласно параметров GUC.

Начиная с конца недели запрос стал падать по спиллу > 30 TB, при том, что особо ничего не поменялось.
В моей реальности, запрос тогда уж должен бы падать всегда, согласно Секрет 26, и объяснить нормальное поведение ДО начала деградации я не в состоянии.

Мне захотелось что-то выжать из этой аномалии, и вот что я узнал.
Если материализовать вью

 
select 
from mart$v
where '2025-11-26'::date >= effective_from_dttm
  and '2025-11-26'::date) < effective_to_dttm;

в таблицу tst_mart из 1 млрд строк, то запрос

explain analyze
select cap_.agreement_rk, vc4_.product_bp_nm
from tst_mart as cap_
         join dict_product as vc4_
              on cap_.product_bp_cd = vc4_.product_bp_cd

отбегает за 2м 18с, но при этом на материализацию tst_mart ушло 6 мин.

Если заглянуть в план, то ожидаемо увидим Broadcast дикта, ибо он без статы, что не критично :

Gather Motion 384:1  (slice2; segments: 384)  (cost=0.00..1507.73 rows=1 width=264) (actual time=9.319..108483.528 rows=990063918 loops=1)
  ->  Hash Join  (cost=0.00..1507.73 rows=1 width=264) (actual time=9.950..1315.095 rows=2583044 loops=1)
        Hash Cond: (tst_mart.product_bp_cd = (tst1500.product_bp_cd)::text)
"        Extra Text: (seg40)  Hash chain length 1.0 avg, 2 max, using 1498 of 524288 buckets."
        ->  Seq Scan on tst_mart  (cost=0.00..498.18 rows=2775858 width=14) (actual time=0.290..450.133 rows=2781093 loops=1)
        ->  Hash  (cost=431.15..431.15 rows=1 width=264) (actual time=6.116..6.116 rows=1500 loops=1)
              ->  Broadcast Motion 384:384  (slice1; segments: 384)  (cost=0.00..431.15 rows=1 width=264) (actual time=0.023..5.667 rows=1500 loops=1)
                    ->  Seq Scan on tst1500  (cost=0.00..431.00 rows=1 width=264) (actual time=0.537..0.544 rows=12 loops=1)
Planning time: 13.347 ms
  (slice0)    Executor memory: 788K bytes.
"  (slice1)    Executor memory: 268K bytes avg x 384 workers, 268K bytes max (seg0)."
"  (slice2)    Executor memory: 4805K bytes avg x 384 workers, 4805K bytes max (seg0).  Work_mem: 145K bytes max."
Memory used:  2129920kB
Optimizer: Pivotal Optimizer (GPORCA)
Execution time: 138661.777 ms

А теперь к сути поста, которая меня крайне заинтересовала.

Если в исходном запросе в справочнике удалить все строки, или оставить, скажем одну из 1500, запрос отрабатывает на раз ( за 2 и 4 с соотв-но )
Это было неожиданно на фоне предыдущих секретов про пустые таблицы (Секрет 1,6).
Проверил снова запрос на полном справочнике - через 9 мин рухнул с workfile per query size limit exceeded.

Возникла шаткая гипотеза, что Broadcast сета из вью mart$v идет только на те узлы, где лежат строки справочника, что хоть как-то объяснило бы, почему запросы отработали.

Т.к. фактический план падающего запроса не проверить, я решил сравнить
теоретический план EXPLAIN с планом EXPLAIN ANALYZE, полученным из запроса на справочнике из 1 строки без статы.

490 viewsedited 13:43