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



Michael:

Also bear in mind that OS/400 and i5/OS is a pure paging system. That is, real main storage is a cache for objects in single-level storage (that reside permanently on DASD). The first time you run your query, those pages containing the needed data (rows) are brought into real main storage memory, and they will remain there until something happens that forces those pages to get paged out or "stolen" for other purposes.

So, even without an index or a plan cache, you can still see what you observed, and that query can seem to run much faster the second and subsequent times.

Also, with more modern IBM i system models, the real main storage sizes are much larger than just a few years ago, so it is even more likely that those pages can remain in main storage for much longer periods before getting replaced ... :-o

The only way I know of to control this, to some extent, for "benchmark" purposes, is to create a separate storage pool and use the SETOBJACC command to "bring" the entire *FILE into the storage pool, then run your query, if you have multiple indexes (or LFs) over the base table, you may also want to issue SETOBJACC for those objects, too. Then, at least you can see "consistent" results of the actual performance of the query itself, taking the system paging out of the equation.



> On 3/23/2011 12:32 PM, Michael Ryan wrote:
Ok...a co-worker had a program with an embedded SQL statement,
selecting records with a number of different criteria. It ran dog
slow. I suggested creating an index to remove some of the 'fixed'
criteria. Did that, recreated the program, ran like the wind. Then we
decided to test things out. Deleted the index. Still ran fast. Used an
old copy of the program that was created before the index was made.
Still ran fast. Deleted the index and the program, recreated the
program. Still ran fast.

What happened? Was an access plan created and stored someplace? I
would think deleting the program and index and recreating the program
would remove any consideration of an access path.

Thanks for any thoughts.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.