Re: putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

""Charles Duffy"" <charles.duffy@gmail.com> 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