On Fri, Feb 16, 2024 at 1:32 PM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > > On 16/2/2024 07:00, jian he wrote: > > On Wed, Feb 14, 2024 at 11:21 AM Andrei Lepikhov > > <a.lepik...@postgrespro.ru> wrote: > > My OS: Ubuntu 22.04.3 LTS > > I already set the max_parallel_workers_per_gather to 10. > > So for all cases, it should use parallelism first? > > > > a better question would be: > > how to make the number of OR less than 29 still faster when > > enable_or_transformation is ON by only set parameters? > In my test environment this example gives some subtle supremacy to ORs > over ANY with only 3 ors and less. > Please, provide next EXPLAIN ANALYZE results for the case you want to > discuss here: > 1. with enable_or_transformation enabled > 2. with enable_or_transformation disabled > 3. with enable_or_transformation disabled but with manual transformation > OR -> ANY done, to check the overhead of this optimization. >
you previously mentioned playing with parallel_tuple_cost and parallel_setup_cost. (https://www.postgresql.org/message-id/e3338e82-a28d-4631-9eec-b9c0984b32d5%40postgrespro.ru) So I did by ` SET parallel_setup_cost = 0; SET parallel_tuple_cost = 0; ` After setting these parameters, overall enable_or_transformation ON is performance better. sorry for the noise. so now I didn't find any corner case where enable_or_transformation is ON peforms worse than when it's OFF. +typedef struct OrClauseGroupEntry +{ + OrClauseGroupKey key; + + Node *node; + List *consts; + Oid scalar_type; + List *exprs; +} OrClauseGroupEntry; I found that the field `scalar_type` was never used.