Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are we done with the sort interrupt issue mentioned in the subject line,
> > and the issue outlined below?
>
> I'm inclined not to apply the proposed patch (adding
> CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are we done with the sort interrupt issue mentioned in the subject line,
> and the issue outlined below?
I'm inclined not to apply the proposed patch (adding
CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
qsort. OTOH you could argue
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
---
Tom Lane wrote:
> "Charles Duffy" <[EMAIL PROTECTED]> writes:
> > ... For the 'long' data, the compare moves on right
"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
12 matches
Mail list logo
