From: | Ba Jinsheng <bajinsheng(at)u(dot)nus(dot)edu> |
---|---|
To: | Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Performance Issue on Query 18 of TPC-H Benchmark |
Date: | 2024-10-16 18:26:12 |
Message-ID: | SEZPR06MB6494FDE43CEBAAEEEB732C918A462@SEZPR06MB6494.apcprd06.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>I believe you are not allowing the optimizer to generate a different aggregation path (Group Aggregate) because it requires a sort operation. So I think this is not correct.
Yes, this is what I did. I though it is what you were asking? I have not found another way to enforce HashAggregate, so I directly modified the code. Can you eliberate why it is incorrect?
>You may notice that disabling parallelism results in improved cardinality estimation and therefore a better query plan, since the optimizer selects paths based on their cost. If parallelism is disabled, query plan have become more correct.
Can I understand disabling parallelism is a good setup for finding performance issues?
Best regards,
Jinsheng Ba
Notice: This email is generated from the account of an NUS alumnus. Contents, views, and opinions therein are solely those of the sender.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-10-16 20:51:34 | Re: Logical Replica ReorderBuffer Size Accounting Issues |
Previous Message | Fujii Masao | 2024-10-16 16:59:10 | Re: [BUGS] BUG #10123: Weird entries in pg_stat_activity |