Re: Query Optimizer

Pete,

*SNIP

....  Does anyone have a clue as to why the query optimizer would chose to
build
a temporary access path with a key that exactly matches the second of two
logical files (no includes or omits)? ........  Does the fact that this is
a logical file (DDS) as
opposed to and SQL index have any bearing on the matter?

*ENDSNIP

Alexei has some very good points about why the optimizer might not use the
index you have created. Sometimes the messages in the job log are poor at
telling you why it takes a certain approach to the data access.   Remember
the first thing the optimizer will do is try to eliminate as many rows from
the query as it can. Based on my experience, the optimizer may in fact be
looking for an EVI (Encoded Vector Index) instead of a binary tree.  The
EVI can only be built in SQL  and is very useful when the row mix has the
right set of keys on it.  An example would be and employee list with
department as a key.  The number of departments is low so the optimizer can
eliminate a great deal of rows prior to even starting an access.  You might
consider creating an EVI for use with your query and see if that helps.

JMHO

Jim Oberholtzer


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---