|
> > was stunned to find the sql faster. > > This is somewhat apocryphal, or at least incomplete > enough to be misleading. I have found that most of us classic RPG folks do not really understand the SQL side of the universe well enough to make general statements about speed. Maybe it's been a bad experience for me, but I have had to troubleshoot plenty of performance issues (multi-million record files are typical). More often than not, an SQL statement can scream when the table is small (test/QA environment), but performance goes right into the dumper when the table is large (production.) This can be from the optimiser not having a proper index to work with (common) or the percentage of records that are selected changes (test database selects 1% of the file, production selects 30% with the same statement.) There are lots of things that change from your environment to mine, and without a good grasp of how the optimiser works, I don't think we (as a community) can readily treat SQL performance in the same way we treat native I/O. The bottom line (bet you thought I'd never get there!) is that native I/O always scales in a linear fashion, but SQL might not. --buck
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.