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
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? |