On Fri, Apr 13, 2012 at 10:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Peter Geoghegan||Date: 2012-04-13 16:42:37|
|Subject: Re: Memory usage during sorting|
|Previous:||From: Robert Haas||Date: 2012-04-13 16:40:09|
|Subject: Re: 9.2 release notes, beta time?|