On 21.09.2011 10:01, Simon Riggs wrote:
> On Wed, Sep 21, 2011 at 7:51 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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?

Nope. Swamped by everything else.

Also note that as soon as the sort grows big enough to not fit in 
maintenance_work_mem, you switch to the external sort algorithm, which 
doesn't use qsort. Perhaps you could do similar inlining in the heap 
sort & merge passes done in the external sort, but it's unlikely to be 
as big a win there.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

• Re: Inlining comparators as a performance optimisation at 2011-09-21 07:01:11 from Simon Riggs

Responses

• Re: Inlining comparators as a performance optimisation at 2011-09-21 12:47:46 from Greg Stark

pgsql-hackers by date

Next:	From: Vlad Arkhipov	Date: 2011-09-21 07:19:34
	Subject: Shared sequence-like objects in PostgreSQL
Previous:	From: Simon Riggs	Date: 2011-09-21 07:01:11
	Subject: Re: Inlining comparators as a performance optimisation