On Thu, 2007-01-04 at 13:17 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > Wouldn't it be better to issue ReadyForQuery() and then issue the stat > > stuff in the gap between processing? > > To me, "ready for query" means "ready for query", not "I think I might > be ready soon". Otherwise you could argue for trying to move the > message emission much further upstream than that. Another problem is > that on a lot of kernels, control swaps to the client process the > instant we issue the send(), and if the client is well-coded control > will swap back when it send()s us the next query. If we rearrange > things as you suggest then the state display will become quite > misleading: it will claim we are still busy when actually the client > has the result, and it will switch to "idle" *after* we've received > a new command.
Yeh, guessed there were some good arguments for the way it was. My thinking was, if the client is local and therefore likely to be fast, we could check for the reply before we signal stats. That way we could avoid posting idle altogether when we are very busy (and therefore would like the extra CPU/path length reduction). OTOH if the client is on the other end of a network, the duration is relatively lengthy and we'll easily be able to do things in the proposed order without a problem. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
