On Tue, Nov 17, 2015 at 6:50 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Tue, Nov 17, 2015 at 12:53 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> Short and sweet! Looks good. > > Thanks. > >> I would be inclined to add more comments to explain it, these things have a >> habit of being forgotten. > > I'm not sure what additional detail I can add. > > 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! 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. I then rebuilt with --disable-float8-byval, because I was worried that case might be harmed by this change. It turns out we win in that case too, just not by as much. The time for the first case doesn't change much, and neither does the unpatched time. The patched time is about 12.9 seconds. I have also reviewed the code, and it looks OK to me, so committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
