Re: disfavoring unparameterized nested loops

On Tue, Jun 15, 2021 at 5:00 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> I don't really think we should solve this by having nodeNestloop.c
> fall back on hashing when the going gets tough. Overloading our nodes
> that way is not a sustainable thing to do. I'd rather see the
> executor throw the plan back at the planner along with some hints
> about what was wrong with it. We could do that providing we've not
> sent anything back to the client yet.

It wasn't a serious suggestion -- it was just a way of framing the
issue at hand that I thought might be useful.

If we did have something like that (which FWIW I think makes sense but
is hard to do right in a general way) then it might be expected to
preemptively refuse to even start down the road of using an
unparameterized nestloop join very early, or even before execution
time. Such an adaptive join algorithm/node might be expected to have a
huge bias against this particular plan shape, that can be reduced to a
simple heuristic. But you can have the simple heuristic without
needing to build everything else.

Whether or not we throw the plan back at the planner or "really change
our minds at execution time" seems like a distinction without a
difference. Either way we're changing our minds about the plan based
on information that is fundamentally execution time information, not
plan time information. Have I missed something?

--
Peter Geoghegan