> It is my understanding that UniData (at least...don't know > about UniVerse) cache's the SELECT in Method 1. You can see > this from ECL by timing a huge select, then CLEARSELECT, then > re-issue the original select. The second run will come back > much quicker.
Caching can be controlled for. I see the 2x to 3x speed difference regardless of which method rins first, or whether I force both to read from disk, or use cache. > Also, Method 2 reads the block from the file and reallocates > the value of "REC" for each iteration, true. > while Method 1 reads > each block once and parses for ID's. It doesn't just parse for ID, it evaluates the record for TYPE = "V". Somehow retrieve is more astute and probably buffers the key & record at one shot when it does its thing, whereas basic grabs only the key (READNEXT), then requires a second request to go after the record. To accomplish the same as retrieve, we'd need a READNEXTRECORD ID,REC command that would return, in one action, the ID and the record. That analysis is consistent with my 2x to 3x speed difference. Except I really expected the 100 x 2 opens + sentence parsing to be significant overhead. > Assuming 10-20 records > per block (recommended file sizing from my UniData Admin > trainer), that's a 10- to 20-fold savings on disk reads. > > --Tom Pellitieri Not in UV. In UV you have the same caching regardless of basic or retrieve. I'm surprised it would be otherwise in UD. For universe, the record and its key are stored together in the group, with the one exception of "Large Records" in Type30 dynamic hashed files. The body of "large records" are stored in their own block in "OVER.30". Retrieveing these via some proposed "READNEXTRECORD ID,REC" would require additional reads like you describe, maybe not 10- or 20-fold difference, though. IIRC, UD routinely (usually? often? always?) stores data more like UV's "large records". - cds ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
