Hi,

Alan,

I don't think you need a userspace with 16MB because SQL/Database itself
blocks in 32K. 
In this way fetching multiple rows into a MOD or array data structure that
is close to 32K and repeating this process several times, may have the same
effect.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)

"If you think education is expensive, try ignorance." (Derek Bok)

"What is worse than training your staff and losing them?  Not training them
and keeping them!"



-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces+hauser=sss-software.de@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+hauser=sss-software.de@xxxxxxxxxxxx] Im Auftrag von
Alan Campin
Gesendet: Tuesday, February 20, 2007 23:46
An: rpg400-l@xxxxxxxxxxxx
Betreff: RE: I need faster SQL 


<snip>
Why need a user space, apperently you are procesing the occurences of the
DS. Using the user space in this regard is overkill. </snip>

Your alternative. Allocate 16MB of memory?

You will note I said "if you are reading in a lot of records". If the
average read only gave you a few records, yes user space is an overkill. If
a single read is going to give dozens or hundreds of records or you simply
don't know what is being returned, the user space makes a lot of sense
because you don't have to manage the storage. The operating system takes
care of it for you and the performance is superb. The IBM manuals make it
clear that whenever possible do a multiple record fetch. 

The only other thing that I can say is I have seen huge differences in
programs where I read the data into a user space. 

At a previous company I was working at I was taking RPG/ILE stored
procedures with call times of over a minutes to sub-second times using this
technique and others. 




 


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.