A learned colleague of mine coded a process that attempted to access the same row on a DB2 table 375 million times per run. (It was a code lookup). When I pointed this out he dismissed my advice by insisting that it didn't matter because the data would be sitting in a DB2 buffer anyway so there would be no I/O cost.
What he didn't reckon on was the CPU path length of the DB2 SELECT statement he was using. It is a long way from Cobol to DB2 and back again even when DB2 doesn't do any I/O. When we changed the process to use an in-core table, the CPU usage dropped from several hours to several minutes.
The moral is: sometimes a little knowledge is more dangerous than no knowledge at all.
skip to main |
skip to sidebar
Comments on Work, technology and life
Some of my favourite links
Followers
Blog Archive
-
▼
2009
(42)
-
▼
November
(30)
- RTFM
- You can't do that with SQL
- HELP
- Debugging tools and oncall support
- RTFC
- Clockwise?
- Buffer this!
- Who do you believe, the programmer or the code?
- Another reason not to share your password
- Practical jokes on the 'frame
- Uninitialized storage (1)
- Masking test data
- Field Name Prefix on DCLGEN command
- ISPF survey
- Advice
- Whose default is it? (sorry)
- Standards are forever
- Oops!
- SDLC: system testing
- SDLC: Production support
- And the survey says.....
- Mythbusting: DB2 results table
- Using I/O subroutines to access DB2 tables
- So you want to do a 7 table join?
- Why FTP?
- Cobol scope terminators
- Some of my best friends are DBAs
- IPT vs ISPF
- Feeling young
- How long should a process take?
-
▼
November
(30)
No comments:
Post a Comment