Skip site navigation (1) Skip section navigation (2)

Re: Threads

From: mlw <pgsql(at)mohawksoft(dot)com>
To: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Serguei Mokhov <mokhov(at)cs(dot)concordia(dot)ca>,Dann Corbit <DCorbit(at)connx(dot)com>,PGHackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Threads
Date: 2003-01-04 03:39:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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.

In response to

  • Re: Threads at 2003-01-04 02:11:17 from Greg Copeland


  • Re: Threads at 2003-01-04 03:38:46 from Greg Copeland

pgsql-hackers by date

Next:From: Oliver ElphickDate: 2003-01-04 04:02:28
Subject: Re: Upgrading rant.
Previous:From: Greg CopelandDate: 2003-01-04 03:38:46
Subject: Re: Threads

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group