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 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 should
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
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 can
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, since
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 mentioning
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 [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 enough
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 generalized
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
sorts of
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
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.
13 matches
Mail list logo
