|
Problem IC62698
|
Status: Closed |
OPTIMIZER NOT ACCOUNTING FOR THE DATA PARTITION ELIMINATION THAT OCCURS IN ONE BRANCH OF IXAND WHEN ADDING THE SECOND BRANCH. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
Query consists of the following two predicates which
can be applied under IXAND:
.
(Q2.SOURCE_SYS_ID = 'CD')
AND (Q2.TRANSACT_TIME < '2009-05-04-23.59.59.000000')
AND
('2009-05-04-00.00.00.000000' < Q2.TRANSACT_TIME)
.
The table is range partitioned on TRANSACT_TIME. The local
equality predicate, Q2.SOURCE_SYS_ID = 'CD'is applied on
one branch of the IXAND and range partition elimination
is applied based on TRANSACT_TIME. However, we again apply
the predicate on TRANSACT_TIME on the other brach of the
IXAND which is not necessary, where purpose is to apply
time predicate on the table, which is already applied
when resolving the local equality predicate.
.
The issue is that the optimizer is not accounting for the data
partition elimination that occurs in the first branch of the
IXAND when adding the second branch to the IXAND.
.
This apar will address this scenario. |
| Problem Summary: |
Query consists of the following two predicates which
can be applied under IXAND:
.
(Q2.SOURCE_SYS_ID = 'CD')
AND (Q2.TRANSACT_TIME < '2009-05-04-23.59.59.000000')
AND
('2009-05-04-00.00.00.000000' < Q2.TRANSACT_TIME)
.
The table is range partitioned on TRANSACT_TIME. The local
equality predicate, Q2.SOURCE_SYS_ID = 'CD'is applied on
one branch of the IXAND and range partition elimination
is applied based on TRANSACT_TIME. However, we again apply
the predicate on TRANSACT_TIME on the other brach of the
IXAND which is not necessary, where purpose is to apply
time predicate on the table, which is already applied
when resolving the local equality predicate.
.
The issue is that the optimizer is not accounting for the data
partition elimination that occurs in the first branch of the
IXAND when adding the second branch to the IXAND.
.
This apar will address this scenario. |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
module engn_sqno
fixed >= v97 fpk1 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 21.08.2009
11.02.2010
11.02.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FPk1
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.1
|
 |
