Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 17, 2012 at 12:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, after writing the code for it I decided to remove creation of
>> parameterized MergeAppendPaths from allpaths.c, though there is still some
>> support for them elsewhere. On reflection it seemed to me that the code
>> was willing to create far too many of these, much more than their
>> potential usefulness could justify (remember that parameterized paths must
>> be on the inside of a nestloop, so their sort ordering is typically of
>> marginal use). We can put that back if we can think of a more restrictive
>> heuristic for when to create them.
> I guess the case in which this would matter is if you wrote something
> like A LJ (B IJ C) where B and/or C has child tables and the best
> method of joining them to each other is a marge join.
Well, we already made a policy decision that we weren't going to try
very hard to support merge joins inside parameterized subtrees, because
the potential growth in planning time looked nasty. My thought was that
we might resurrect the parameterized MergeAppendPath code when and if
we reverse that decision. At the moment, in fact, I believe that
add_path is pretty nearly guaranteed to discard a parameterized
MergeAppendPath immediately upon submission, because the fact that it's
sorted isn't given any weight for add_path comparisons, and cost-wise
it's going to look worse than the similarly parameterized plain Append
that we would have submitted just before.
>> Second, I've gotten dissatisfied
>> with the terminology "required_outer" that was used in the original param
>> plans patch. I'm considering a global search and replace with
>> "param_relids" or some variant of that.
> Personally, I find required_outer more clear. YMMV.
Perhaps. What's bothering me is the potential for confusion with outer
joins; the parameter-supplying rels are *not* necessarily on the other
side of an outer join. Anybody else have an opinion about that?
regards, tom lane
