Re: Why enable_hashjoin Completely disables HashJoin

On Tue, 4 Apr 2023 at 11:18, Andres Freund <andres(at)anarazel(dot)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