Well, my understanding of the query used was a single key field query based on an indexed key. This would involve simply reading the index entry, and then doing hash reads on the records contained in that index key.
When sorting, at least on some systems, we do have a parallel/threaded sort engine to perform a merge-sort similar to what you describe. Just didn't seem that this called for such a need. Dave -----Original Message----- From: Robert Colquhoun To: U2 Users Discussion List Sent: 3/30/2004 7:01 PM Subject: RE: Modern Universe (TESTING) Hello Dave, At 09:36 AM 31/03/2004, [EMAIL PROTECTED] wrote: >However, one thing I did want to address is your QUAD processor point. >You've made it a few times, and I just had to point out that it is >irrelevant to the discussion. While UV will take native advantage of >multi-processors in it's execution, a single query executed by a single >user, especially such as that listed, will execute on a single processor, so >no benefits will be seen for being on a QUAD (or a 64-way) machine. Just curious about the above - why does it have to be that way? You are reading in groups one at a time and then merging them into the main list. Surely you can have at least one thread read in the records(as this takes a long time) and at least one other do an insertion sort on the group and a merge sort on the main list simultaneously. If you use a merge sort you should be able to break it into how many ever processors are available then merge each processors final sub-list together to get the result. - Robert -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
