Re: [PERFORM] qsort again

From: Ron <rjpeace(at)earthlink(dot)net>
To: Florian Weimer <fw(at)deneb(dot)enyo(dot)de>,pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PERFORM] qsort again
Date: 2006-02-16 13:38:45
Message-ID: 7.0.1.0.2.20060216082618.03ad7e48@earthlink.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

At 07:10 AM 2/16/2006, Florian Weimer wrote:
>* Neil Conway:
>
> > On Wed, 2006-02-15 at 18:28 -0500, Tom Lane wrote:
> >> It seems clear that our qsort.c is doing a pretty awful job of picking
> >> qsort pivots, while glibc is mostly managing not to make that mistake.
> >> I haven't looked at the glibc code yet to see what they are doing
> >> differently.
> >
> > glibc qsort is actually merge sort, so I'm not surprised it avoids this
> > problem.
>
>qsort also performs twice as many key comparisons as the theoretical
>minimum.

The theoretical minimum number of comparisons for a general purpose
comparison based sort is O(lgN!).
QuickSort uses 2NlnN ~= 1.38NlgN or ~1.38x the optimum without tuning
(see Knuth, Sedgewick, Corman, ... etc)
OTOH, QuickSort uses ~2x as many =moves= as the theoretical minimum
unless tuned, and moves are more expensive than compares in modern systems.

See my other posts for QuickSort tuning methods that attempt to
directly address both issues.

Ron

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-02-16 13:39:13 Re: Doubt in parser
Previous Message Ron 2006-02-16 13:22:55 Re: qsort again (was Re: [PERFORM] Strange Create Index

Browse pgsql-performance by date

  From Date Subject
Next Message Markus Schaber 2006-02-16 13:44:45 Re: qsort again (was Re: [PERFORM] Strange Create Index
Previous Message Peter Childs 2006-02-16 13:32:34 Re: Postgres slower than MS ACCESS