Doug McNaught wrote:
> A very valid objection. I'm also dubious as to the utility of the
> whole concept. What happens when Sendmail refuses a message based on
> load? It is requeued on the sending end to be tried later. What
> happens when PG refuses a new client connection based on load? The
> application stops working. Is this really better than having slow
> response time because the server is thrashing?
That's exactly the point why I suggested to delay transaction
starts instead. The client app allways gets the connection.
Doing dialog steps inside of open transactions is allways a
bad design, leading to a couple of problems (coffee break
with open locks), so we can assume that if an application
starts a transaction, it'll keep this one backend as busy as
possible until the transactions end.
Processing too many transactions parallel is what get's the
system into heavy swapping and exponential usage of
resources. So if we delay starting transactions if the system
load is above the limit, we probably speedup the overall per
transaction response time, increasing the througput. And
that's what this discussion is all about, no?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
