Agreed - IGNORE_DERIVED_INDEX is now the default since v6r1 - it means
that select/omit indexes are not a reason not to use SQE. Go for it!!
In one of our product I now bundle a custom QAQQINI - if a customer
gives the user profile in question *JOBCTL, then I use CHGQRYA to point
to our library location for the QAQQINI file. It might help some
queries, although I'm running into "translation required" as the reason
for staying in CQE. Shared-weight sort sequence seems to be part of the
problem - Visual Explain doesn't indicate in an obvious way what I need
to do. Have created several shared-weight indexes to go along with the
unique-weight ones, and the right ones are being used.
OK - that' MY rant!!!
Charles Wilt wrote:
95% of the time, the SQE is better for a given query than CQE. IIRC
correctly, the only pervasive issue I've heard about was with queries
contained in JD Edwards, but IBM/Oracle had some PTFs for those. I
think there's a knowledge base article on it.
Point out to your powers that be that at 6.1, IBM changes the system
default so that IGNORE_DERIVED_INDEXES = *YES.
I had ours changed in the middle of the day on a system with 800+
users and haven't looked backed.
On Fri, Aug 28, 2009 at 8:53 AM, Jonathan
We have an SQL statement that uses the CQE and runs extremely slowly. In test I have created an Encoded Vector Index and also changed a local version of the QAQQINI file so that the IGNORE_DERIVED_INDEXES is set to *YES.
With these settings the SQL runs extremely fast, however the powers that be are nervous about changing a global setting that would potentially affect all SQL requests.
I've spent the morning talking to my friend, Google, and searching through the Midrange.com archives, and everything I have seen indicates that using the SQE is better than using the CQE.
With this in mind, are there any pitfalls in changing the IGNORE_DERIVED_INDEXES setting to *YES? Should we expect all SQL to run at least as fast as does currently or is there a risk that some SQL processes could run slower?
Thanks in advance
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives