Re: What is the practical limitation of no multi-threading? - Mailing list pgsql-general

From Doug McNaught
Subject Re: What is the practical limitation of no multi-threading?
Date
Msg-id m37kru4zjw.fsf@belphigor.mcnaught.org
Whole thread Raw
In response to What is the practical limitation of no multi-threading?  (Brian Beuning <bbeuning@mindspring.com>)
List pgsql-general
"Robert B. Easter" <reaster@comptechnews.com> writes:

> Not being multithreaded may only be a big deal if your application connects
> and disconnects from the database at high rates.  In that situation, such an
> application would suffer the poorer performance of multiprocess servers like
> Postgres since it is significantly more time consuming to copy the memory
> management unit (mmu) state, or at least to load a new program image (the
> backend), than with threads which share mmu state and program image.

Absolutely true, but in such a case you should be using connection
pooling on the client side anyhow, as even threaded commercial
databases (Oracle/Informix etc) have a lot of connection startup
overhead.

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

pgsql-general by date:

Previous
From: "Robert B. Easter"
Date:
Subject: Re: use BLOBS or use pointers to files on the filesystem?
Next
From: "Robert B. Easter"
Date:
Subject: Re: problem with select after updating