Re: Performance Issue on Query 18 of TPC-H Benchmark

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.

In response to

Responses

Browse pgsql-bugs by date

  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