× 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 don't think anyone knows enough to make general
> statements.  That's why I ran tests.

As usual, I didn't make my point very clearly.

Here's the scenario.  A pair of absolutely identical iSeries systems.  CPU
model, feature code, PTF levels, everything EXCEPT for the number of records
in otherwise identical databases.  So the ONLY difference between the two
systems is the number of records in the databases.

Run some timings on an unloaded system A using READ.  Each READ will take a
certain amount of time per record.  Run the same tests on an unloaded system
B and your timings will turn out practically identical.  You can extrapolate
that a READ for n records will take (N * READ time) and you'd be really
close.

Perform the same tests with SQL and the results on the emptier database will
not extrapolate to the fuller one.  You cannot predict what the system
response time will be based on your tests.  You cannot use your tests to
prove anything at all except what performance is for ONE and ONLY ONE
system/dataset combination.  MY SQL testing means literally nothing to
anyone else.

This sounds extreme but fits my experience base very well.

As for the talk about system performance, it is up to the database and
system admin to configure a properly performing _system_
(hardware/software/database.)  A programmer is unlikely to have the
political motivation to spend the time required to optimise the whole
shebang.  I believe this to be true (admin should optimise) of both native
I/O (since the introduction of OPNQRYF) and SQL I/O.

The major difference between the two in my opinion is that native I/O tests
can be used as a firm basis for extrapolating the performance of the
application in production.  SQL I/O tests cannot.  Classical RPG programmers
starting to use SQL often treat SQL as if it were RPG spoken with a funny
accent.  This is a mistake, in my opinion, and the cause of many performance
problems.

All my opinion, and none personal.  Just a note about my experience for the
archives.  I'll shut up now.
  --buck




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.