<br /><br /> Greg Copeland wrote:<br /><blockquote cite="mid1041646276.15927.202.camel@mouse.copelandconsulting.net"
type="cite"><prewrap=""> </pre><blockquote type="cite"><pre wrap="">Of course that gives up the hope of faster
connectionstartup that has
always been touted as a major reason to want Postgres to be threaded...
regards, tom lane </pre></blockquote><pre wrap="">
Faster startup, should never be the primary reason as there are many
ways to address that issue already. Connection pooling and caching are
by far, the most common way to address this issue. Not only that, but
by definition, it's almost an oxymoron. If you really need high
performance, you shouldn't be using transient connections, no matter how
fast they are. This, in turn, brings you back to persistent connections
or connection pools/caches.</pre></blockquote> Connection time should *never* be in the critical path. There, I've said
it!!People who complain about connection time are barking up the wrong tree. Regardless of the methodology, EVERY OS
hasissues with thread creation, process creation, the memory allocation, and system manipulation required to manage
it.Under load this is ALWAYS slower. <br /><br /> I think that if there is ever a choice, "do I make startup time
faster?"or "Do I make PostgreSQL not need a dump/restore for upgrade" the upgrade problem has a much higher impact to
realPostgreSQL sites.<br />
