Re: Why enable_hashjoin Completely disables HashJoin

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> 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.

Yeah, we'd have to be sure that all that preliminary work is teased apart
from the actual path-making. I think we are probably pretty close to
that but not there yet. Subqueries might be problematic, but perhaps
we could define our way out of that by saying that this retry principle
applies independently in each planner recursion level.

> 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?

As I commented concurrently, I think we should simply not try to solve
that conundrum: if you want control, don't pose impossible problems.
There's no principled way that we could decide which of enable_hashagg
and enable_sort to ignore first, for example.

regards, tom lane