"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
straightforward.
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.
--
greg
---------------------------(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
