|
I think Vern hit it on the head. A cursorless SQL SELECT INTO still bags the overhead of opening/closing the file. It just must do it faster than coding our own cursor, (as Joe has determined). I know we can emulate the following traditional for x = 1 to number; open(e) myfile; chain(e) x myfile; close(e) myfile; endfor; While that test might be more apples to apples it has no application whatsover in the real world. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com |-----------------------------+-------------------------------------------| | Vern Hamberg | | | <vhamberg@centerfieldtechn| | | ology.com> | To| | Sent by: | Midran| | midrange-l-bounces@midrang| ge | | e.com | System| | | s | | 07/23/2004 03:52 PM | Techni| | | cal | | Please respond to | Discus| | Midrange Systems | sion | | Technical Discussion | <midra| | <midrange-l@xxxxxxxxxxx| nge-l@| | m> | midran| | | ge.com| | | > | | | cc| | | | | | Subject| | | RE: | | | SQL | | | vs. | | | tradit| | | ional | | | I/O? | | | | | | | | | | | | | | | | | | | |-----------------------------+-------------------------------------------| It depends on what you want to test. I think Mark P. said it well - when doing regression testing, I guess I'd call it, you want to start from the same point. In this case, if you are comparing just how each engine works as a unit or component, you'd probably want to eliminate other variables. But that's only one kind of test. Another kind is what you ARE doing, which is repeated runs, to see what happens then. Even here, you might want to clear the air. When I was testing in the DB lab at IBM, we often had warmup runs that we excluded from the results, so that we could test, as much as possible, a steady-state environment. Then there's the need to do real-world simulations. That's even harder. Just look at the work the TPC organization does for benchmarks. Lots of reasons to do things different ways. But in your valid quest for meaningful information we want also to be sure we minimize random influences. In the case of your tests that use SELECT INTO, it may be that the SQL engine is still doing some open/close activity. It'd be useful to run the DBMON against your program, to see what is really going on with SQL. This run would not be useful for performance comparisons, only to gather information on how it is running. Oh, and, before using DBMON, maybe STRDBG would give a hint of things. And it is possible with QAQQINI settings to get even more information in the job log. Most of those settings are documented and available in InfoCenter and probably somewhere at <www.iseries.ibm.com/db2>. Vern At 03:43 PM 7/23/2004, you wrote: > > From: Vern Hamberg > > > > Joe, it's not really caching, it's just the result of data being in >memory > > that is available to all processes. Unit testing would need you to >CLRPOOL > > and SETOBJACC *PURGE in order to compare apples to apples. Another >kind of > > testing would be what you are doing now, to show what happens when you > > leave things in memory. > >Um, why would I need to CLRPOOL to compare "apples to apples"? Are you >saying that somehow CLRPOOL will make SQL run better? Why? Does SQL >not know how to take advantage of memory? If so, that's a knock on SQL, >not my testing. Since I would never be doing a CLRPOOL in production, >why would I do it in a test? > >Just trying to find out what you consider "apples to apples" to really >mean. > >Joe > >-- >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. -- 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 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.
midrange.com
