Jeff Davis wrote:<br /><blockquote cite="mid:1198193593.10057.72.camel@dogma.ljc.laika.com" type="cite"><blockquote
type="cite"><prewrap="">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. </pre></blockquote><pre wrap="">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. </pre></blockquote> It's probably not a relevant
scenarioeither, as this discussion has only been about improving the performance of the sort, and I suspect there are
veryfew database loads with performance characteristics completely defined by the efficiency of the sort algorithm?
:-)<br/><br /> So far I am getting:<br /><br /> 1) Sort is slower than many people expect. (Jeff's test case
emphasizesthis well)<br /> 2) White papers exist that document theoretical, simulated, and in some cases actual
executionwhere parallel sort can be beneficial.<br /> 3) White papers exist that document how parallel sort is
difficultto get right, and that characteristics of machines in use today prevent full utilization.<br /> 4)
PostgreSQLis not designed to spread a single query across multiple execution units (whether CPUs, cores, or HT).<br
/><br/> It's interesting discussion for me thus far.<br /><br /> Cheers,<br /> mark<br /><br /><pre
class="moz-signature"cols="72">--
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>
