Jeff Davis wrote:
Where parallel processing like this becomes attractive is when you're running
a 2 hour query on a machine sequentially running scheduled batch jobs which
can be sped up to 30 minutes. But in that case you're almost certainly being
limited by your disk bandwidth, not your cpu speed.
Are you sure that's always the case? My test seemed to indicate that
sorting took longer than it would to read the file from disk.
It's probably not a relevant scenario either, as this discussion has
only been about improving the performance of the sort, and I suspect
there are very few database loads with performance characteristics
completely defined by the efficiency of the sort algorithm? :-)
So far I am getting:
1) Sort is slower than many people expect. (Jeff's test case
emphasizes this well)
2) White papers exist that document theoretical, simulated, and in
some cases actual execution where parallel sort can be beneficial.
3) White papers exist that document how parallel sort is difficult
to get right, and that characteristics of machines in use today prevent
full utilization.
4) PostgreSQL is not designed to spread a single query across
multiple execution units (whether CPUs, cores, or HT).
It's interesting discussion for me thus far.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>
