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
Charles Duffy [EMAIL PROTECTED] writes:
On 7/12/06, Qingqing Zhou [EMAIL PROTECTED] wrote:
the problem here is that 29247 doesn't look like a big number so I can't see
why your patch solved the problem, unless the qsort_comparetup() function of
the data type eats too many circles or the cpu is
Charles Duffy [EMAIL PROTECTED] writes:
[ CHECK_FOR_INTERRUPTS inside qsort comparison routine ]
It occurs to me that there's a nonzero risk of problems here, because if
the interrupt occurs qsort() will lose control. I'm wondering whether
there are any implementations of qsort() that allocate
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
Peter Eisentraut [EMAIL PROTECTED] writes:
The merge sort is here:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/msort.c?rev=1.21content-type=text/x-cvsweb-markupcvsroot=glibc
It uses alloca, so we're good here.
Uh ... but it also uses malloc, and potentially a honkin' big malloc at
Charles Duffy [EMAIL PROTECTED] writes:
Their work_mem setting was rather large (100). We determined that when it
received SIGINT, the backend was always inside qsort(), so it wouldn't
call ProcessInterrupts() again until it finished this large in-memory
sort. Upon entering
