Greg Copeland wrote:
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 has issues with thread creation, process creation, the memory allocation, and system manipulation required to manage it. Under load this is ALWAYS slower.Of course that gives up the hope of faster connection startup that has always been touted as a major reason to want Postgres to be threaded...regards, tom laneFaster 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.
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 real PostgreSQL sites.
