Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?
От | Peter Geoghegan |
---|---|
Тема | Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY? |
Дата | |
Msg-id | CAM3SWZQ+Zvmy2zCE+cOBQ9XMAxMAszeCv=zn=RY-WUiAFM_A0w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up
CREATE INDEX CONCURRENTLY?
|
Список | pgsql-hackers |
On Wed, Dec 16, 2015 at 12:28 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I seem to be able to produce these sorting patches at a much greater >> rate than they can be committed, in part because Robert is the only >> one that ever reviews them, and he is only one person. > > I object to that vicious slander. I am at least three people, if not more! I was referring only to the Robert that reviews my sorting patches. :-) > Meanwhile, I did some simple benchmarking on your latest patch on my > MacBook Pro. I did pgbench -i -s 100 and then tried: > > create index x on pgbench_accounts (aid); > create index concurrently x on pgbench_accounts (aid); > > The first took about 6.9 seconds. The second took about 11.3 seconds > patched versus 14.6 seconds unpatched. That's certainly a healthy > improvement. That seems pretty good. It probably doesn't matter, but FWIW it's likely that your numbers are not as good as mine because this ends up with a perfect logical/physical correlation, which the quicksort precheck [1] does very well on when sorting the TIDs (since input is *perfectly* correlated, as opposed to 99.99% correlated, a case that does poorly [2]). > I have also reviewed the code, and it looks OK to me, so committed. Thanks! [1] Commit a3f0b3d68f9a5357a3f72b40a45bcc714a9e0649 [2] http://www.postgresql.org/message-id/54EB580C.2000904@2ndquadrant.com -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: