From: | <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gabriele Bartolini <angusgb(at)tin(dot)it>, Aaron Werman <awerman2(at)hotmail(dot)com> |
Subject: | Re: Re: Data warehousing requirements |
Date: | 2004-10-08 12:38:01 |
Message-ID: | 28292295$10972388454166893d146f88.44056315@config5.schlund.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)com> wrote on 08.10.2004, 07:53:26:
>
> > It's not so much that they are necessarily inefficient as that they
> > constrain the planner's freedom of action. You need to think a lot more
> > carefully about the order of joining than when you use inner joins.
>
> I've also found that OUTER JOINS constrain the types of joins that can/will be
> used as well as the order. Maybe you didn't intend it that way, but (for
> example) OUTER JOINs seem much more likely to use expensive merge joins.
>
Unfortunately, yes thats true - thats is for correctness, not an
optimization decision. Outer joins constrain you on both join order AND
on join type. Nested loops and hash joins avoid touching all rows in
the right hand table, which is exactly what you don't want when you
have a right outer join to perform, since you wish to include rows in
that table when there is no match. Thus, we MUST choose a merge join
even when (if it wasn't an outer join) we would have chosen a nested
loops or hash.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-08 13:55:56 | Re: [PERFORM] stats on cursor and query execution troubleshooting |
Previous Message | Harald Fuchs | 2004-10-08 12:28:52 | Re: integer[] indexing. |