On Thu, 2005-12-15 at 19:06 -0500, 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.) We could do the deferred send fairly easily. You need only set a timer when stats_command_string = on, so we'd only do that when requested by the admin. Overall, that would be a cheaper way of doing it than now. However, I'm more inclined to the idea of a set of functions that allow an administrator to retrieve the full SQL text executing in a backend, with an option to return an EXPLAIN of the currently executing plan. Right now, stats only gives you the first 1000 chars, so you're always stuck if its a big query. Plus we don't yet have a way of getting the exact EXPLAIN of a running query (you can get close, but it could differ). Pull is better than push. Asking specific backends what they're doing when you need to know will be efficient; asking them to send their command strings, all of the time, deferred or not will always be more wasteful. Plus if you forgot to turn on stats_command_string before execution, then you've no way of knowing anyhow. Best Regards, Simon Riggs
