[HACKERS] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ReadyForQuery()
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. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ReadyForQuery()
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
