RE: Should we still be using select/omit in logical files?

Vern has answered your question, so I'll just remark on this:

Hey, SQL just might use the S/O logical!!

Only if CQE is executing the query. SQE does not have that capability yet.
Not to say IBM won't enhance it to do so in the future.

Elvis


Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: Re: Should we still be using select/omit in logical files?

No - the term DERIVED INDEX means a select./omit - I suggest doing a
google search on the term below and find all you can - I think the
explanations are clear and worth looking.

This value controls whether the optimizer will be the new query engine
or the old one, when there are select/omit logicals against the physical
file you are querying.

Remember, you should almost never use a logical file in you SELECT
statement. Although it forces you to the old query engine, it is OK to
use a select/omit in your SELECT if you want to take advantage of its
selectivity. It is probably less confusing, however, to put that
selectivity into a WHERE clause, so that it is explicitly stated, and
use the based-on PF. Hey, SQL just might use the S/O logical!!

Regards
Vern

David FOXWELL wrote:

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Elvis Budimlic
- even when querying PFs, mere existence of an S/O LF may
cause a query to be routed to CQE. That is, unless there is
an IGNORE_DERIVED_INDEX setting in QUSRSYS/QAQQINI set to
*YES, or you're on V6R1 (that's the default setting for that
version of the OS), or your S/O LF is defined with the DYNSLT keyword

I'm not sure if I understand that : does IGNORE_DERIVED_INDEX stop the use

of all indexes if I just reference the PF in the SQL instruction?