"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> Comparing the behavior of this to my patch for HEAD, I am coming to the
>> conclusion that this is actually a *better* planning method than
>> removing the redundant join conditions, even when they're truly
>> rendundant! The rea
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Would it be a good idea to keep removing redundant clauses and rethink
> the preference for clauseful joins, going forward?
No --- it would create an exponential growth in planning time for large
join problems, while not actually buying anything in the
Tom Lane wrote:
> Comparing the behavior of this to my patch for HEAD, I am coming to the
> conclusion that this is actually a *better* planning method than
> removing the redundant join conditions, even when they're truly
> rendundant! The reason emerges as soon as you look at cases involving
>
I wrote:
> Haven't looked closely at how to fix 8.2, yet.
After some study it seems that the simplest, most reliable fix for 8.2
is to dike out the code that removes "redundant" outer join conditions
after propagating a constant across them. This gives the right answer
in the cases of concern (wh
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> There was a serious performance regression in OUTER JOIN planning
> going from 8.2.4 to 8.2.5. I know Tom came up with some patches to
> mitigate the issues in 8.2.5, but my testing shows that problems
> remain in 8.3beta4.
Please try the attached p
