On Fri, Apr 13, 2012 at 10:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> After some reflection I think that the blame should be pinned on >>> have_relevant_joinclause(), which is essentially defined as "is there >>> any join clause that can be evaluated at the join of these two >>> relations?". I think it would work better to define it as "is there any >>> join clause that both these relations participate in?". > >> I think it's getting a little late in the day to be whacking the >> planner around too much, but I have to admit that seems like a pretty >> good and safe change to me, so maybe we should go ahead and do it. >> I'm a bit worried, though, that with all the planner changes this >> release we are going to spend a lot of time tracking down regressions >> either in planning time or in plan quality. > > Could be. I think though that this fits in pretty naturally with the > parameterized-path changes, since both of them are really directed > towards being able to apply inner indexscans in cases where we could > not before.
Yeah, I had the same thought. I am more worried that either the changes we made for index-only scans or the parameterized paths stuff is going to turn out to introduce nasty, as-yet-unforeseen regressions. But at this point we're in for that pain whatever we do about this. -- 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
