On Wed, Sep 21, 2011 at 7:51 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 21.09.2011 02:53, Peter Geoghegan wrote: >> >> C stdlib quick-sort time elapsed: 2.092451 seconds >> Inline quick-sort time elapsed: 1.587651 seconds >> >> Does *that* look attractive to you? > > Not really, to be honest. That's a 25% speedup in pure qsorting speed. How > much of a gain in a real query do you expect to get from that, in the best > case? There's so many other sources of overhead that I'm afraid this will be > lost in the noise. If you find a query that spends, say, 50% of its time in > qsort(), you will only get a 12.5% speedup on that query. And even 50% is > really pushing it - I challenge you to find a query that spends any > significant amount of time qsorting integers.
How about almost every primary index creation? Don't really see a reason for the negativity here. If you use that argument no performance gain is worth it because all workloads are mixed. This is a marvellous win, a huge gain from a small, isolated and easily tested change. By far the smallest amount of additional code to sorting we will have added and yet one of the best gains. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
