putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

From: "Charles Duffy" <charles(dot)duffy(at)gmail(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: putting CHECK_FOR_INTERRUPTS in qsort_comparetup()
Date: 2006-07-11 07:25:33
Message-ID: dfdaea8f0607110025p43c6b96ahfa95d02ed7ba3af5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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 (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.

The patch puts a CHECK_FOR_INTERRUPTS in qsort_comparetup. This solves
their problem, at the cost of checking InterruptPending a lot. The
"unlikely()" gcc directive might help there a bit.

I'm not sure if this patch has general applicability - but it seems to
solve the problem for our client. Does anyone think it might introduce
any new problems?

Thanks,

--
Charles Duffy

Attachment Content-Type Size
tuplesort.patch text/x-patch 868 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Katsuhiko Okano 2006-07-11 11:09:24 poor performance with Context Switch Storm at TPC-W.
Previous Message Tom Lane 2006-07-11 03:24:24 Re: CTIDs invalidations and dropping columns.

Browse pgsql-patches by date

  From Date Subject
Next Message Katsuhiko Okano 2006-07-11 11:09:24 poor performance with Context Switch Storm at TPC-W.
Previous Message Dave Page 2006-07-10 21:57:20 Minor ipv6/Win32 fix