Thanks chief. I'll keep an eye out for
any outer joins misbehaving.
Cheers
Nuno Souto
[EMAIL PROTECTED]
http://www.users.bigpond.net.au/the_Den
- Original Message -
_PUSH_JOIN_PREDICATE is set to TRUE or the accessing query contains
the
PUSH_PRED hint.
--
Please see the official
- Original Message -
Have run across some interesting things while reading up on the
optimizer.
Same here! :-)
Always thought that the RBO joins your tables in the order found in
the
FROM clause? Think again.
Actually, I found one in Metalink that says with RBO, it's the reverse
On Monday 28 May 2001 04:45, Nuno Souto wrote:
Always thought that the RBO joins your tables in the order found in
the FROM clause? Think again.
Actually, I found one in Metalink that says with RBO, it's the reverse
order of the FROM clause. Which I was aware of. But it also
says: if
On Monday 28 May 2001 04:45, Nuno Souto wrote:
And a few others. I found out the problem I reported
a while ago with CBO suddenly going South on hash scan joins and
completely ignoring nested loops or indexes is actually an introduced
problem due to a change in CBO rules after 8.0.4. It
Have run across some interesting things while reading up on the optimizer.
First of all, there is a very interesting paper on MetaLink titled
Cost Based Optimizer - Common Misconceptions and Issues.
This is note 35934.1.
Among other things, it makes it clear under what conditions the CBO
Isn't elimination of common subexpressions the default in 8.1.7? Also, the optimizer
is sometimes overzealous and eliminates essential expressions. My source for this is
Peoplesoft which suggests setting
optimizer_features_enable = 8.1.6
When using their products against an 8.1.7
Ian,
There are some bugs in 8.1.7.0 to do with common subquery elimination
(1578644 and 1651014 and maybe others).
These bugs may be fixed in 8.1.7.1.2 and / or 8.1.7.1.3 (I am currently
trying to get clarification from Oracle on this).
Also see Metalink note 137430.1.
Regards,
Bruce
