I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
continue to exist, but its effect on left/right joins will be the same as
for inner joins. If anyone wants to force join order for outer joins more
than
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Why the thing about the mergejoinable conditions then? Is that even
> true?
There are some things that work off mergejoinable conditions, but the
equivalence of right and left join isn't one of them ...
regards, tom lane
-
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I wonder if the code is already able to transform right joins to left
> > joins, like
> > (A rightjoin B on (Pab)) = (B leftjoin A on (Pab))
>
> Yeah, we already know that part. It's a freebie --- I didn't even
> bother mentioni
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder if the code is already able to transform right joins to left
> joins, like
> (A rightjoin B on (Pab)) = (B leftjoin A on (Pab))
Yeah, we already know that part. It's a freebie --- I didn't even
bother mentioning rightjoin in my post, sin
Tom Lane wrote:
> I've spent some time looking into how we can improve our planning of outer
> joins. The current planner code slavishly follows the syntactic join
> order, which can lead to quite bad plans. The reason it does this is that
> in some cases altering the join order of outer joins ca
On Thu, 2005-12-15 at 09:25 -0500, Tom Lane wrote:
> I did find some papers that talked about ways to push joins up and down
> past aggregations and GROUP BY, but that's a problem for another day.
Yes, they seem like a good thing to get round to... the papers seem to
present them as fairly clear
On Wed, 2005-12-14 at 21:27 -0500, Tom Lane wrote:
> I've spent some time looking into how we can improve our planning of outer
> joins.
Sounds good.
> I'm not sure whether we'd need any additional planner knobs to control
> this. I think that the existing join_collapse_limit GUC variable shou
I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
continue to exist, but its effect on left/right joins will be the same as
for inner joins. If anyone wants to force join order for outer joins more
than
I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
continue to exist, but its effect on left/right joins will be the same as
for inner joins. If anyone wants to force join order for outer joins more
than
On Thu, Dec 15, 2005 at 09:25:42AM -0500, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> There is some stuff in the literature about how to make transformations
> >> of the last kind, but it requires additional executor smarts to do strange
>
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> There is some stuff in the literature about how to make transformations
>> of the last kind, but it requires additional executor smarts to do strange
>> sorts of "generalized outer join" operations.
> Would these "g
Tom Lane <[EMAIL PROTECTED]> writes:
> There is some stuff in the literature about how to make transformations
> of the last kind, but it requires additional executor smarts to do strange
> sorts of "generalized outer join" operations.
Would these "generalized outer join" operations be general
I've spent some time looking into how we can improve our planning of outer
joins. The current planner code slavishly follows the syntactic join
order, which can lead to quite bad plans. The reason it does this is that
in some cases altering the join order of outer joins can change the
results. H
13 matches
Mail list logo
