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