Re: Threads

Greg Copeland wrote:

>
>
>>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 lane
>>
>>
>
>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.
>
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.

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.