Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
Дата
Msg-id CADkLM=fHkXx6NBNuEvZh_sQAynRkAH4qgaHNhV7iMYEk5=_bYg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 16, 2015 at 4:24 PM, Peter Geoghegan <span
dir="ltr"><<ahref="mailto:pg@heroku.com" target="_blank">pg@heroku.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 16,
2015at 12:28 PM, Robert Haas <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> wrote:<br />
>>I seem to be able to produce these sorting patches at a much greater<br /> >> rate than they can be
committed,in part because Robert is the only<br /> >> one that ever reviews them, and he is only one person.<br
/>><br /> > I object to that vicious slander.  I am at least three people, if not more!<br /><br /></span>I was
referringonly to the Robert that reviews my sorting patches.  :-)<br /><span class=""><br /> > Meanwhile, I did some
simplebenchmarking on your latest patch on my<br /> > MacBook Pro.  I did pgbench -i -s 100 and then tried:<br />
><br/> > create index x on pgbench_accounts (aid);<br /> > create index concurrently x on pgbench_accounts
(aid);<br/> ><br /> > The first took about 6.9 seconds.  The second took about 11.3 seconds<br /> > patched
versus14.6 seconds unpatched.  That's certainly a healthy<br /> > improvement.<br /><br /></span>That seems pretty
good.It probably doesn't matter, but FWIW it's<br /> likely that your numbers are not as good as mine because this ends
up<br/> with a perfect logical/physical correlation, which the quicksort<br /> precheck [1] does very well on when
sortingthe TIDs (since input is<br /> *perfectly* correlated, as opposed to 99.99% correlated, a case that<br /> does
poorly[2]).<br /><span class=""><br /> > I have also reviewed the code, and it looks OK to me, so committed.<br
/><br/></span>Thanks!<br /><br /> [1] Commit a3f0b3d68f9a5357a3f72b40a45bcc714a9e0649<br /> [2] <a
href="http://www.postgresql.org/message-id/54EB580C.2000904@2ndquadrant.com"rel="noreferrer"
target="_blank">http://www.postgresql.org/message-id/54EB580C.2000904@2ndquadrant.com</a><br/><span
class="HOEnZb"><fontcolor="#888888">--<br /> Peter Geoghegan<br /></font></span><div class="HOEnZb"><div class="h5"><br
/><br/> --<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers" rel="noreferrer"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></div></div></blockquote></div><br
/></div><divclass="gmail_extra">My apologies to Peter and all the Roberts, I wasn't able to set up a test fast enough.
Gladit got committed.</div><div class="gmail_extra"><br /></div><div class="gmail_extra"><br /></div><div
class="gmail_extra"><br/></div></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Fwd: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"