Re: Add a greedy join search algorithm to handle large join problems
| От | Tomas Vondra |
|---|---|
| Тема | Re: Add a greedy join search algorithm to handle large join problems |
| Дата | |
| Msg-id | 5abd6054-413c-4f48-9172-d8b31062b266@vondra.me обсуждение исходный текст |
| Ответ на | Re: Add a greedy join search algorithm to handle large join problems (Chengpeng Yan <chengpeng_yan@Outlook.com>) |
| Ответы |
Re: Add a greedy join search algorithm to handle large join problems
|
| Список | pgsql-hackers |
On 12/2/25 14:04, Chengpeng Yan wrote:
> Hi,
>
>
>
>> On Dec 2, 2025, at 18:56, Tomas Vondra <tomas@vondra.me> wrote:
>>
>> I think a much broader evaluation will be needed, comparing not just the
>> planning time, but also the quality of the final plan. Which for the
>> starjoin tests does not really matter, as the plans are all equal in
>> this regard.
>
>
> Many thanks for your feedback.
>
> You are absolutely right — plan quality is also very important. In my
> initial email I only showed the improvements in planning time, but did
> not provide results regarding plan quality. I will run tests on more
> complex join scenarios, evaluating both planning time and plan quality.
>
I was trying to do some simple experiments by comparing plans for TPC-DS
queries, but unfortunately I get a lot of crashes with the patch. All
the backtraces look very similar - see the attached example. The root
cause seems to be that sort_inner_and_outer() sees
inner_path = NULL
I haven't investigated this very much, but I suppose the GOO code should
be calling set_cheapest() from somewhere.
regards
--
Tomas Vondra
Вложения
В списке pgsql-hackers по дате отправления: