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
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 |
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 |