Re: Sorting Improvements for 8.4 - Mailing list pgsql-hackers

Jeff Davis wrote: <blockquote cite="mid:1198105396.10057.23.camel@dogma.ljc.laika.com" type="cite"><pre wrap="">On
Wed,2007-12-19 at 15:51 -0500, Mark Mielke wrote:  </pre><blockquote type="cite"><pre wrap="">That sounds possible, but
Istill feel myself suspecting that disk
 
reads will be much slower than localized text comparison. Perhaps I am
overestimating the performance of the comparison function?   </pre></blockquote><pre wrap="">I think this simple test
willchange your perceptions: </pre></blockquote> Yes - I received the same results (although my PostgreSQL doesn't have
abuilt in case ::text::bytea... :-) )<br /><br /><blockquote cite="mid:1198105396.10057.23.camel@dogma.ljc.laika.com"
type="cite"><prewrap="">On my machine this table fits easily in memory (so there aren't any disk
 
reads at all). Sorting takes 7 seconds for floats, 9 seconds for binary
data, and 20 seconds for localized text. That's much longer than it
would take to read that data from disk, since it's only 70MB (which
takes a fraction of a second on my machine). </pre></blockquote> Might this mean that PostgreSQL performs too many copy
operations?:-)<br /><br /><blockquote cite="mid:1198105396.10057.23.camel@dogma.ljc.laika.com" type="cite"><pre
wrap="">Ithink this disproves your hypothesis that sorting happens at disk
 
speed. </pre></blockquote> Yes.<br /><br /><blockquote cite="mid:1198105396.10057.23.camel@dogma.ljc.laika.com"
type="cite"><blockquotetype="cite"><pre wrap="">Yep - I started to read up on it. It still sounds like it's a hard-ish
 
problem (to achieve near N times speedup for N CPU cores without
degrading performance for existing loads), but that doesn't mean
impossible. :-)   </pre></blockquote><pre wrap="">You don't even need multiple cores to achieve a speedup, according
to
Ron's reference. </pre></blockquote> I think Ron's reference actually said that you don't need full cores to achieve a
speedup.It spoke of Intel's HT system. A single CPU with a single execution pipeline is not going to function better
withmultiple threads unless the single thread case is written wrong. Multiple threads is always an overall loss without
hardwaresupport. The thinking on this is that multiple threads can sometimes lead to cleaner designs, which are
sometimesmore naturally written to be performing. In my experience, the opposite is usually true.<br /><br /> But, if
youdo have HT, and the algorithm can be modified to take advantage of it for an overall increase in speed - great.<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>