Re: What is the practical limitation of no multi-threading?

From: Doug McNaught <doug(at)wireboard(dot)com>
To: "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com>
Cc: Brian Beuning <bbeuning(at)mindspring(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: What is the practical limitation of no multi-threading?
Date: 2001-12-10 19:58:59
Message-ID: m37kru4zjw.fsf@belphigor.mcnaught.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Robert B. Easter" <reaster(at)comptechnews(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Robert B. Easter 2001-12-10 20:03:46 Re: problem with select after updating
Previous Message Robert B. Easter 2001-12-10 19:41:00 Re: use BLOBS or use pointers to files on the filesystem?