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.


-----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
list.  Surely you can have at least one thread read in the records(as
takes a long time) and at least one other do an insertion sort on the
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
processors are available then merge each processors final sub-list
to get the result.

  - Robert

u2-users mailing list
u2-users mailing list

Reply via email to