| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Ba Jinsheng <bajinsheng(at)u(dot)nus(dot)edu>, "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 06:28:25 |
| Message-ID: | 44b42d35-2283-4a7f-aa2d-a9abe2dcf1b6@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 10/16/24 01:28, Ba Jinsheng wrote:
> The major differerence between both query plans is the first one has
> additional *SORT*. I believe the second query plan is more efficient.
> Similar to my last report, perhaps we can optimize code to enable it.
I would like to know if you can improve that case by switching from the
sorted group to a hashed one.
I see huge underestimation because of the HAVING clause on an aggregate.
It would be interesting to correct the prediction and observe what will
happen.
Can you reproduce the same query using the SQL server? It would
highlight some techniques Postgres has not adopted yet.
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2024-10-16 08:20:41 | Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault |
| Previous Message | Ba Jinsheng | 2024-10-16 05:58:59 | Re: Performance Issue on Query 18 of TPC-H Benchmark |