""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 that "unacceptably long time"?
> Their work_mem setting was rather large (1000000). 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 tuplesort_performsort(), state->memtupcount was
> 29247.
>
I agree that we may need to consider to let qsort() check interrupts, but
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 too slow. I just did a
test to invoke a qsort on an "integer" field of a table with 5 million rows,
and sent a SIGINT, the delay is 7 or 8 seconds. I suspect there are some
other places doesn't check interrupts -- what's your query plan?
Regards,
Qingqing
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
