Re: Question of Parallel Hash Join on TPC-H Benchmark

>I wonder if you have any progress in that area. Living nearby Singapore
(Chon Buri, Thailand) I would like to visit meetup related to this
problem, if you organised it.

That is great! Unfortunately, I have moved to ETH Zurich, Switzerland as a postdoc from last month.
Our research is still on early exploration stage, and we would happy to talk more about it when we have made a significant progress.

>Of course, reporting performance issues is always beneficial.
Sounds good! I will report more cases when I believe are real performance issues.

Best regards,

Jinsheng Ba

________________________________
From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Sent: Sunday, October 13, 2024 11:57 AM
To: Ba Jinsheng <bajinsheng(at)u(dot)nus(dot)edu>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>; Zhang Mingli <zmlpostgres(at)gmail(dot)com>; pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Question of Parallel Hash Join on TPC-H Benchmark

- External Email -

On 13/10/2024 15:57, Ba Jinsheng wrote:
> Thanks for looking into it!
> We are working a research project to automatically look for such cases.
> If it matters for PostgreSQL, I will report more such cases.
I made an attempt last year [1]. However, at least in production, it
provided too many false-positive cases to trigger automatic
re-optimisation [2] on each poorly estimated query plan.
I wonder if you have any progress in that area. Living nearby Singapore
(Chon Buri, Thailand) I would like to visit meetup related to this
problem, if you organised it.
Of course, reporting performance issues is always beneficial.

[1] https://github.com/danolivo/pg_track_optimizer
[2] https://postgrespro.com/docs/enterprise/16/realtime-query-replanning

--
regards, Andrei Lepikhov

Notice: This email is generated from the account of an NUS alumnus. Contents, views, and opinions therein are solely those of the sender.