× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I changed it to *YES at both my current company and the previous and
everything seems to work alright. You could turn it on and see if there are
issues and if there are use Ops Nav to see what indexes are being
recommended.

On Fri, Aug 28, 2009 at 11:08 AM, McGovern, Sean <Sean.McGovern@xxxxxxxxxxxx
wrote:

I know that Infor recommend changing the IBM i 6.1 setting for
IGNORE_DERIVED_INDEXES back to *NO for BPCS / ERP LX installations. For
these, the majority (75% +) of the indexes are logical files with
Select/Omit criteria. Ignoring all the those indexes results in a slower
sytem overall, even though the SQE engine is faster.


________________________________

From: midrange-l-bounces@xxxxxxxxxxxx on behalf of Jonathan Mason
Sent: Fri 28/08/2009 13:53
To: midrange-l@xxxxxxxxxxxx
Subject: CQE, SQE and QAQQINI



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.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.