Thursday, March 6, 2008

Native hash full outer join in Oracle 11g

One of the new features of Oracle 11g that does not have that much of marketing attention is the new support for native full outer joins if they can be handled by a HASH join operation, whichs means that it needs to be an equi-join. Of course you need to use the ANSI join syntax (FULL OUTER JOIN) rather than the traditional Oracle syntax for outer joins (+) in order to benefit from the new feature

In comparison to the method used so far for full outer joins the new native support should require less resource consumption as it is able to perform the full outer join in one single operation whereas the former implementation required a rewrite of the full outer join to a simple outer join (left or right) and an additional "not exists" operation, e.g. handled by a further hash-join anti which would require another access to the data, e.g. two table scans instead of a single one.

This new functionality seems to be controlled by the internal parameter "_optimizer_native_full_outer_join". It currently supports three different settings: "choose", "force" and "off". The default is "force", and setting it to any other value for me disabled the new feature, so in my tests there was no difference between "choose" and "off", but of course there might be cases where "choose" actually attempts to use the new feature.

You can modify this parameter e.g. using ALTER SESSION or the OPT_PARAM hint that has been introduced with Oracle 10g that allows to manipulate parameter values only for a specific statement execution rather than for the whole session.

Here is a small sample script that demonstrates the new feature in action.

First it creates two tables using the ALL_OBJECTS view. In a 11g default installation these tables hold approx. 53.000 records. The two tables are generated using a certain offset for the join column so that they overlap only partially. Hence a full outer join on that column is supposed to return the overlapped part and each part from each table that doesn't overlap.

You can see that the database was able to perform the join operation in one single HASH JOIN FULL OUTER step. It is interesting to note that the cardinality estimate in this particular case does not consider the non-overlapping parts and just returns the cardinality of a complete overlapping set.

Now we revert to the pre-11g implementation by disabling the new feature.

It is obvious that in this particular case the database had to do more work. It required two operations, an outer join and a second anti join to perform the full outer join operation. It can also be seen that the "consistent gets" are doubled due to that second operation. On the other hand, the cardinality estimate looks closer to reality, as it considers at least partially the non-overlapping part represented by the anti join operation.

For the sake of completeness the following query shows that the new feature is only available for equi-joins, since this is the only operation supported by a hash join.