Re: putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

Qingqing,

On 7/12/06, Qingqing Zhou <zhouqq@cs.toronto.edu> 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 eats too many circles or the cpu is too slow.

Well...when exhibiting the problem, execution stays inside qsort() for
the entire 'delay period' - I don't think its off in some other recess
which is also lacking in interrupt flag checking.

As for the CPU - the machine is a 4 way Opteron, and otherwise
performs well. It does seem odd that the in-memory sort takes as long
as it does - the plan may suggest a reason.

And - the patched version doesn't exhibit the problem.

> 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?

Plan attached.

Thanks,

Charles Duffy