On Fri, Apr 13, 2012 at 10:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane <tgl@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
