Re: Sorting Improvements for 8.4
От | Mark Mielke |
---|---|
Тема | Re: Sorting Improvements for 8.4 |
Дата | |
Msg-id | 476AF8D0.80900@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: Sorting Improvements for 8.4 (Jeff Davis <pgsql@j-davis.com>) |
Список | 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>
В списке pgsql-hackers по дате отправления: