Tom Lane wrote: > Michael Fuhr <mike@xxxxxxxx> writes: > > Does the backend support, or could it be easily modified to support, > > a mechanism that would post the command string after a configurable > > amount of time had expired, and then continue processing the query? > > Not really, unless you want to add the overhead of setting a timer > interrupt for every query. Which is sort of counterproductive when > the motivation is to reduce overhead ... > > (It might be more or less free if you have statement_timeout set, since > there would be a setitimer call anyway. But I don't think that's the > norm.) Actually, it's probably not necessary to set the timer at the beginning of every query. It's probably sufficient to just have it go off periodically, e.g. once every second, and thus set it when the timer goes off. And the running command wouldn't need to be re-posted if it's the same as last time around. Turn off the timer if the connection is idle now and was idle last time around (or not, if there's no harm in having the timer running all the time), turn it on again at the start of the next transaction. In essence, the backend would be "polling" itself every second or so and recording its state at that time, rather than on every transaction. Assuming that doing all that wouldn't screw something else up... -- Kevin Brown kevin@xxxxxxxxxxxxxx
