Re: sql exec speed. was AS/400 STILL wearing the undeserved "closed system" moniker

>
>I'm still waiting for someone to explain to me how SELECT and UPDATE can be
>faster than CHAIN/UPDAT for normal transaction processing.
>


Joe, You dont read my posts??<g>

I speculated that roch could be writing new code for sql that is optimized
for the power pc processor.  Store and retain the search keys in registers,
minimize flushes of the instruction pipeline, take advantage of the chips
ability to execute instructions in parellel.

On a system with multiple processors, use one cpu to search and maintain a
buffer of the most recent accessed rcds.  Use another cpu to run the
standard binary tree search.  Use the results of the method that returns the
soonest.

It is a good question Joe.
If my speculation is on the right track, I am interested in knowing more
about how it is actually done.

Steve Richter




>
>> I like LF's; they're highly intuitive (or more intuitive than SQL coding)
>> and easy to share across programs and applications (which reduces
>> the chance
>> of program errors caused by mismatched SQL coding).
>
>Standardizing SQL access via stored procedures is a way around this, but as
>I've said in the past, by the time you get to stored procedures, you should
>be writing servers.  With servers you get full control of the database,
>including features such as granular security (at the field content level)
>and recovery/restart (unlike COMMIT/ROLLBACK, with recovery/restart you can
>actually finish a partially completed transaction when your server comes
>back up).
>
>
>> Yes, SQL is the way of the future,
>
>I think the jury is still out on this issue.  I've seen large applications
>that were converted to SQL access and the performance suffered horribly.
In
>these days of more cost-conscious IS departments, the concept of having to
>buy a grossly overpowered server just so that you have the option of miving
>to a DIFFERENT grossly overpowered server isn't particularly fiscally
>responsible.  And that's why I shake my head when someone says "SQL
performs
>better than native access".  At what?  Certainly not at transaction
>processing!
>
>And that's why I've worked so hard on my revitalization techniques - so
that
>you can write applications in native RPG and run them over a web interface
>on a box that supports dozens - even hundreds - of users for a low
>six-figure total cost (and without the associated costs of a fleet of
>network and database administrators).
>
>Joe
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>
>