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



Buck's correct. All those things affect performance.

My rule of thumb is simple. If there are less than 5 - 8 rows in the I/O
record level access and SQL are going to be about a push in speed. Over 8
rows with a properly tuned DB/2, SQL is going win every time. The trick is
properly tuning DB/2.

Memory and type/number of indexes are critical, but so is the automatic
tuning. If the auto tune feature is turned on you are making the query
engine really work harder than it has to. In a heavy SQL environment I
always turn it off to allow the Query engine to do its job more efficiently.
We then tune the memory pools manually.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck
Calabro
Sent: Friday, July 24, 2015 5:17 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SQL Insert - performance

On 7/24/2015 4:30 AM, Kevin Passey wrote:
Is it any more efficient to add records in an RPG program using
embedded SQL Insert, rather than opening a file in RPG the traditional
way and writing records..

There is only one 100% sure thing in computing, and that's the answer to any
performance question. Which is: It Depends.

Some variables to consider / describe:
Blocking in RLA?
Number of indexes?
Memory pool size?
Number of rows to insert?
Number of rows in the table before the inserts?
Sparse keys? No keys at all?
DASD type?
IBM i version?

I personally approach performance like this:
Measure.
Change one thing.
Measure.

--
--buck

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

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.