Re: Why enable_hashjoin Completely disables HashJoin

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Why enable_hashjoin Completely disables HashJoin
Дата
Msg-id CAApHDvq6fjvuqKQJO_LK1Aw2O3LayqZsGL44Qa3b+S8tre+h7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why enable_hashjoin Completely disables HashJoin  (Andres Freund <andres@anarazel.de>)
Ответы Re: Why enable_hashjoin Completely disables HashJoin  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, 4 Apr 2023 at 11:18, Andres Freund <andres@anarazel.de> wrote:
> It sounds too hard compared to the gains, but another way could be to plan
> with the relevant path generation hard disabled, and plan from scratch, with
> additional scan types enabled, if we end up being unable to generate valid
> plan.

I think there would be quite a bit of work to do before we could ever
start to think about that.  The planner does quite a bit of writing on
the parse, e.g adding new RangeTblEntrys to the query's rtable. We'd
either need to fix all those first or make a copy of the parse before
planning. The latter is quite expensive today.  It's also not clear to
me how you'd know what you'd need to enable again to get the 2nd
attempt to produce a plan this time around. I'd assume you'd want the
minimum possible set of enable_* GUCs turned back on, but what would
you do in cases where there's an aggregate and both enable_hashagg and
enable_sort are both disabled and there are no indexes providing
pre-sorted input?

David

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Why enable_hashjoin Completely disables HashJoin
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why enable_hashjoin Completely disables HashJoin