Alright, curiosity got the better of me and Ihad to recast the
solution using Christian's suggestion and compare the two. Forthwith
the RITA summary of each:
Single lookup solution:
81715.646 ms attributed to stages; 2 virtual I/Os.
6 pipeline specifications used (116 stages).
544125 pipeline specifications issued.
0.003 ms in general overhead.
41433.749 ms in scanner.
628.510 ms in commands.
36008.492 ms in dispatcher.
0.000 ms in hunt.
169295.734 ms in accounting overhead.
329082.134 ms total.
Dual lookup solution:
81117.195 ms attributed to stages; 2 virtual I/Os.
4 pipeline specifications used (114 stages).
544122 pipeline specifications issued.
0.003 ms in general overhead.
40106.315 ms in scanner.
571.333 ms in commands.
34568.210 ms in dispatcher.
0.000 ms in hunt.
165632.322 ms in accounting overhead.
321995.378 ms total.
Pretty close, but the dual lookup solution wins by a hair.
--
bc
On Fri, Aug 7, 2009 at 4:54 PM, Bob Cronin<[email protected]> wrote:
> Oh, and fwiw speed really isn't a major concern. This task only runs 6
> times a day (and currently takes about 10 minutes, elapsed). That's
> acceptable and a 10% gain isn't really all that compelling given that
> the existing process is stable.
> --
> bc
>
> On Fri, Aug 7, 2009 at 3:09 PM, Glenn Knickerbocker<[email protected]> wrote:
>> Christian Reichetzeder wrote:
>>> This might spoil the party, but why not splitting the reference in
>>> contractors
>>> and non-contractors and using two lookup stages.
>>
>> I tried a brief test of this, splitting up numbers with and without
>> zeroes--I can't say "quick test" since it took figuring out that my
>> NXPIPE MODULE was old, finding what I did wrong in trying to download it
>> back in April, and going back and looking up how to get it right!
>>
>> With about a half-million master records (numbers up to a million with a
>> 1 in them, split between numbers with and without zeroes) and a thousand
>> detail records (square numbers up to a million), it worked out about 5%
>> slower, but it sure seems a lot cleaner. Then I thought to try it with
>> more detail records, and saw that the two separate searches are a lot
>> faster once the masters are loaded. With a million detail records, the
>> whole mess came out 12% faster.
>>
>> ¬R
>>
>
