whinit: WHERE ((I=1) and (J>5) and (MOD(K, 3)=2))
whinit: wh-tree presented
/-NAME = [I]
/-CEQ----|
|
\-LITN = [1]
--LAND---|
|
/-NAME = [J]
|--CGT----|
|
\-LITN = [5]
|
/-FUNC = [MOD()]
|
/-FLST---|
|
| |--NAME = [K]
|
| \-LITN = [3]
\-CEQ----|
\-LITN = [2]
whinit: wh-tree after split
/-FUNC = [MOD()]
/-FLST---|
|
|--NAME = [K]
|
\-LITN = [3]
--CEQ----|
\-LITN = [2]
whinit: SBM-INDEX IJK uses 1% of sges(WITHIN maxsegratio 75%)
whinit: SBM-INDEX J uses at least 76% of segs(EXCEEDS maxsegratio 75%)
whinit: INDEX tree after split
/-NAME = [I] <1>SBM-INDEX IJK (I)
/-CEQ----|
|
\-LITN = [1]
--LAND---|
|
/-NAME = [J] <2>SBM-INDEX J (J)
\-CGT----|
\-LITN = [5]
whinit returns: ALL EVAL1(w/SEGLIST) EVAL2
Here, the indexes on
column i, a composite index on the columns
(i j k), and the column j are
combined. In this example, WHINIT uses both EVAL1 and EVAL2. The j predicate
involves an inequality operator (greater than). Therefore, WHINIT
cannot combine the predicate with i and the
composite index involving i and j (and k).
Using the composite
index ijk in this plan might be inefficient.
If a smaller composite index (that is, one on i j or
a simple index on i) were available, WHINIT
would select it. In lieu of this, try benchmarking the plan. Suppress
the composite index and compare the results to the existing plan to
see which is more efficient (faster) on your machine.
The example that follows
shows what WHINIT's plan would look like with the composite index
suppressed.