Subject: | |
From: | |
Reply To: | |
Date: | Fri, 14 Mar 1997 19:03:55 -0800 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
We were recently doing some testing of a KSAM/CM file with over 60,000
duplicate keys, and thought of KSAM/xl as a possible solution to the
poor performance we were seeing. Adding a new duplicate key to KSAM/CM
was taking about 40 CPU seconds, but KSAM/xl took over 500 CPU
seconds! We know that this many duplicate keys are going to be a
problem (our user had started to used a 'keyed' field to store one of
two possible values, our application wouldn't attempt to store blanks
in the KSAM, but would (and did) place over 60,000 keys of 'P'... we
are adding an option not to place the values in the field into the
KSAM), but didn't expect KSAM/xl to be worse (especially that much
worse!).
Any ideas what's causing this?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
John Park 'Everything works,
Corvallis, Oregon if you let it.'
[log in to unmask] -Meatloaf
|
|
|