On 7/15/06, Tom Lane [EMAIL PROTECTED] wrote:
Anyway, Qingqing's question still needs to be answered: how can a sort
of under 30k items take so long?
It happens because (as previously suggested by Tom) the dataset for
the 'short' (~10k rows, .3 sec) sort has no rows whose leftmost fields
Charles Duffy [EMAIL PROTECTED] writes:
... For the 'long' data, the compare moves on rightward until it
encounters 'flato', which is a TEXT column with an average length of
7.5k characters (with some rows up to 400k). The first 6 columns are
mostly INTEGER, so compares on them are relatively
Tom Lane wrote:
We might have to just tolerate this, but if it occurs on a lot of
platforms I'd have second thoughts about applying the patch. Anyone
familiar with the internals of glibc's qsort, in particular?
Doesn't look like it's allocating any nonlocal memory:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
We might have to just tolerate this, but if it occurs on a lot of
platforms I'd have second thoughts about applying the patch. Anyone
familiar with the internals of glibc's qsort, in particular?
Doesn't look like it's allocating any
Tom Lane wrote:
Doesn't look like it's allocating any nonlocal memory:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/qsort.c?rev=1.
12content-type=text/x-cvsweb-markupcvsroot=glibc
But this file defines _quicksort() not qsort(). I was under the
impression that the latter is
