"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 rela
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
eva
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The merge sort is here:
> http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/msort.c?rev=1.21&content-type=text/x-cvsweb-markup&cvsroot=glibc
> It uses alloca, so we're good here.
Uh ... but it also uses malloc, and potentially a honkin' big mallo
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.
> >12&content-type=text/x-cvsweb-markup&cvsroot=glibc
>
> But this file defines _quicksort() not qsort(). I was under the
> impression that the lat
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 alloc
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:
http://sourceware.org/cg
"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 alloc
"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 o
"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 tuples
