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?
|
Список | 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 по дате отправления: