Обсуждение: ReadyForQuery()

In postgres.c main loop, I note that we issue ReadyForQuery() *after*
updating pgstat and setting the ps display.

Wouldn't it be better to issue ReadyForQuery() and then issue the stat
stuff in the gap between processing? 

That way we would be less likely to care about pgstat and the ps,
potentially getting rid of the GUCs for them completely?

(I'm looking to place a PG_TRACE macro in there, so we can work out how
long is spent waiting for client.)

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com

"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.
        regards, tom lane

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