This is impacting version 9.7 FP9 only.
Join predicate expression may throw run time error such as
overflow, divide by 0, or casting error. This behavior is as
designed and complies with SQL standard. The purpose of this
APAR is to reduce the risks of hitting this kind of problem.
In version 9.7 FP9, the DB2 query rewrite is able to push down
expression equality join predicate, called jPrd, to sub query in
order for the optimizer to plan MSJOIN and HSJOIN; otherwise
only NLJOIN would be considered for jPrd. Such expression,
called JExp, push down is restricted to columns output from
GROUP BY, UNION, and UNION ALL sub query. When there is local
predicate, called lPrd, applied on top of the same sub query,
lPrd used to be not pushed down into the sub query. The
predicate evaluation order is free for DB2 optimizer to
determine from the access plan costing perspective. For example,
the desirable predicate order forms better index start-stop key
if index scan is available. This doesn't necessarily take
expression run time error into consideration. Either jPrd or
lPrd may have expression whose computation over the entire sub
query may get run time error, such as overflow, divide by 0, or
casting error, whereas applying one before another may avoid the
run time error. DB2 compiler doesn't have to worry about the run
time error when it determines the predicate order. But if lPrd
is simple comparison predicate, it has no expression so it won't
cause any run time error, and pushing it down to the sub query
can reduce the chance of run time error from computing jExp. |
