On Tue, Apr 17, 2012 at 3:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
OK. >>> 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? Well, we also use the words "inner" and "outer" to refer to the sides of any join, regardless of type. Maybe we could call it "requires_nestloop_with" or "requires_join_to" or something like that. The thing I don't like about "param_relids" is that "param" can refer to an awful lot of different things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
