From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | simon(at)2ndquadrant(dot)com |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org, Gabriele Bartolini <angusgb(at)tin(dot)it>, Aaron Werman <awerman2(at)hotmail(dot)com> |
Subject: | Re: Re: Re: Data warehousing requirements |
Date: | 2004-10-08 14:22:44 |
Message-ID: | 12169.1097245364@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
<simon(at)2ndquadrant(dot)com> writes:
> 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.
The alternative of course is to flip it around to be a left outer join
so that we can use those plan types. But depending on the relative
sizes of the two tables this may be a loser.
If you are using a FULL join then it is indeed true that mergejoin is
the only supported plan type. I don't think that was at issue here
though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pallav Kalva | 2004-10-08 14:49:12 | Query Tuning |
Previous Message | Tom Lane | 2004-10-08 14:03:26 | Re: integer[] indexing. |