On Thu, 2007-01-04 at 13:17 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> 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