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.
In response to
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|