"Charles Duffy" <[EMAIL PROTECTED]> writes:
> The patch puts a CHECK_FOR_INTERRUPTS in qsort_comparetup.
Just to close out this thread: this is now done for 8.2, per discussion
here:
http://archives.postgresql.org/pgsql-hackers/2006-10/msg00144.php
regards, tom lane
-
"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
Qingqing,
On 7/12/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
>
How long is that "unacceptably long time"?
30 seconds.
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 ea
""Charles Duffy"" <[EMAIL PROTECTED]> wrote
>
> We came up with this patch in response to a problem reported to us by a
> client. They had a query which took an unacceptably long time to respond
> to a cancel request (SIGINT). The client uses 8.1.4, so the patch is
> against that.
>
How long is th
Hi,
We came up with this patch in response to a problem reported to us by a
client. They had a query which took an unacceptably long time to respond
to a cancel request (SIGINT). The client uses 8.1.4, so the patch is
against that.
Their work_mem setting was rather large (100). We determined
12 matches
Mail list logo
