Re: Enforcing Parameterised Nested Loop Join Order for Foreign Table Joins - Mailing list pgsql-general

From Adam Zegelin
Subject Re: Enforcing Parameterised Nested Loop Join Order for Foreign Table Joins
Date
Msg-id 25F7A104-6A3E-48F4-B993-20B0A8353528@relational.io
Whole thread Raw
In response to Re: Enforcing Parameterised Nested Loop Join Order for Foreign Table Joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Enforcing Parameterised Nested Loop Join Order for Foreign Table Joins
List pgsql-general
Thanks for your assistance Tom.

On 19/03/2013, at 12:40 PM, Tom Lane <tgl@sss.pgh.pa.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



Attachment

pgsql-general by date:

Previous
From: Aleksey Tsalolikhin
Date:
Subject: Re: Need advice on best system to choose
Next
From: Tom Lane
Date:
Subject: Re: Enforcing Parameterised Nested Loop Join Order for Foreign Table Joins