Hi Greg, Recently, I was keeping evaluating performance of this patch(1/28 V13). Here I find a regression test case which is parallel insert with bitmap heap scan. when the target table has primary key or index, then the patched performance will have a 7%-19% declines than unpatched.
Could you please have a look about this? I tried max_parallel_workers_per_gather=2/4/8, and I didn't tune other parameters(like GUCs or other enforce parallel parameters). 1. max_parallel_workers_per_gather=2(default) target_table patched master %reg ------------------------------------------------------ without_PK_index 83.683 142.183 -41% with_PK 382.824 321.101 19% with_index 372.682 324.246 15% 2. max_parallel_workers_per_gather=4 target_table patched master %reg ------------------------------------------------------ without_PK_index 73.189 141.879 -48% with_PK 362.104 329.759 10% with_index 372.237 333.718 12% 3. max_parallel_workers_per_gather=8 (also set max_parallel_workers=16, max_worker_processes = 16) target_table patched master %reg ------------------------------------------------------ without_PK_index 75.072 146.100 -49% with_PK 365.312 324.339 13% with_index 362.636 338.366 7% Attached test_bitmap.sql which includes my test data and sql if you want to have a look. Regards, Tang
test_bitmap.sql
Description: test_bitmap.sql
