Re: CQE, SQE and QAQQINI

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!!!

Vern

Charles Wilt wrote:

Johnathan,

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.

Charles Wilt
Software Engineer
Cintas Corp.


On Fri, Aug 28, 2009 at 8:53 AM, Jonathan
Mason<jonathan.mason@xxxxxxxxxxxxxxxx> wrote:

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

Jonathan



--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.