Re: Enforcing Parameterised Nested Loop Join Order for Foreign Table Joins

Thanks for your assistance Tom.

On 19/03/2013, at 12:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I think you missed my point: you should not be insisting on a maximal
> set of required outer rels.

I’ve started generating multiple paths for the web services that support it, which works great.

> In this particular case, it won't generate a cross-product join of l1
> and l2 because there's a heuristic that says that's unlikely to be a
> good idea. But in related cases, there could be join order restrictions
> that *require* us not to do the joins in that order; so even if you
> could talk us out of applying that heuristic, this code is still subject
> to undesirable failures. You really need to provide three paths using
> the three possible combinations of outer rels.

Certain web services I’m connecting to explicitly require parameters, often multiple ones.
I check the quals and if any required values are not present I simply raise an error.
So really, it is a “good idea” in my case.
Queries that require different join orders will still fail because all required quals are not present.

Is this heuristic a tuneable parameter, or something that would require a logic change inside the planner itself?

Regards,
Adam