Thanks for your assistance Tom. On 19/03/2013, at 12:40 PM, Tom Lane <tgl@xxxxxxxxxxxxx> 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: smime.p7s>>
