Serge,
That is true for inner joins - I tested with three tables only in the sample
database.
Still, I checked again on the sample database using outer joins:
2 statements returning the same:
a)select c.projname, a.firstnme, a.lastname, b.deptno
from employee a inner join department b on a.empno=b.mgrno left outer join
project c on c.deptno=b.deptno
b)select c.projname, a.firstnme, a.lastname, b.deptno
from department b left outer join project c on c.deptno=b.deptno inner join
employee a on b.mgrno = a.empno
but resulting in different access plans and slightly different costs.
The optimized SQL returns for
a)SELECT Q4.PROJNAME AS "PROJNAME", Q3.$C2 AS "FIRSTNME", Q3.$C1 AS
"LASTNAME",
Q3.$C0 AS "DEPTNO"
FROM
(SELECT Q2.DEPTNO, Q1.LASTNAME, Q1.FIRSTNME
FROM U48JTO.EMPLOYEE AS Q1, U48JTO.DEPARTMENT AS Q2
WHERE (Q1.EMPNO = Q2.MGRNO)) AS Q3 LEFT OUTER JOIN U48JTO.PROJECT AS Q4 ON
(Q4.DEPTNO = Q3.$C0)
b)SELECT Q3.$C2 AS "PROJNAME", Q4.FIRSTNME AS "FIRSTNME", Q4.LASTNAME AS
"LASTNAME", Q3.$C1 AS "DEPTNO"
FROM
(SELECT Q2.MGRNO, Q2.DEPTNO, Q1.PROJNAME
FROM U48JTO.PROJECT AS Q1 RIGHT OUTER JOIN U48JTO.DEPARTMENT AS Q2 ON
(Q1.DEPTNO = Q2.DEPTNO)) AS Q3, U48JTO.EMPLOYEE AS Q4
WHERE (Q3.$C0 = Q4.EMPNO)
Any comments ?
Juliane
Serge Rielau wrote:
Hi Paul,
When using the explicit JOIN syntax, you force the optimizer to choose that
join order, in your case first t2 and t3 and then t1.
(I just tried it again using empty tables to proove it is still this way in
V8)
I don't this is correct in DB2 V8 for LUW at least.
Without join reordering life in the optimizer would be rather dull ... ;-)
--
Message posted via
http://www.dbmonster.com