"Charles Duffy" <[EMAIL PROTECTED]> writes:

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

It occurs to me that this kind of thing is something dtrace could help with.
It might even be able to do something clever like "time between consecutive
CHECK_FOR_INTERRUPT calls grouped by the function that postgres spent the most
time in between those points". If not that then something like "grouped by the
first function call in the intervening period" is probably pretty

Of course this is complicated by CHECK_FOR_INTERRUPTS being a macro... perhaps
a probe could be added in that macro. In fact I suspect many of the locations
we'll need manually added probes will be macros.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to