On Wed, Feb 14, 2024 at 11:21 AM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > > So, this example is more about the subtle balance between > parallel/sequential execution, which can vary from one platform to another. >
Hi, here I attached two files, expression_num_or_1_100.sql, expression_num_or_1_10000.sql it has step by step test cases, also with the tests output. For both sql files, I already set the max_parallel_workers_per_gather to 10, work_mem to 4GB. I think the parameters setting should be fine. in expression_num_or_1_100.sql: main test table: create table test_1_100 as (select (random()*1000)::int x, (random()*1000) y from generate_series(1,1_000_000) i); if the number of OR exceeds 29, the performance with enable_or_transformation (ON) begins to outpace enable_or_transformation (OFF). if the number of OR less than 29, the performance with enable_or_transformation (OFF) is better than enable_or_transformation (ON). expression_num_or_1_10000.sql enable_or_transformation (ON) is always better than enable_or_transformation (OFF). 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?
expression_num_or_1_100.sql
Description: application/sql
expression_num_or_1_10000.sql
Description: application/sql
