Re: [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup() - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()
Date
Msg-id 87psgbl9ea.fsf@stark.xeocode.com
Whole thread Raw
List pgsql-hackers
"Charles Duffy" <charles.duffy@gmail.com> 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



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: row() is [not] null infelicities
Next
From: ITAGAKI Takahiro
Date:
Subject: Re: passing parameters to CREATE INDEX