On Thu, 7 Feb 2002, mlw wrote:
>
> Going from a "process model" to a "threaded model" is a HUGE
> undertaking. In the process model, all data is assumed to be private,
> and shared data must be explicitly shared. In a threaded model all data
> is implicitly shared and private data must be explicitly made private.
> Do not under estimate what this means or how hard it is to convert one
> to the other.
>
I agree with the first and last sentance ... the rest of the paragraph is
... well we argued this before - look in the archives.
> Also:
>
> Think of file handles. In a threaded version of postgreSQL, all
> connections will be competing for file handles. I think the limit in
> Linux is 1024.
Depends on how it is done.
> All threads will be competing for memory mapping. As systems get more
> and more RAM, on the x86 and other 32 bit machines, process space is
> limited to 2 to 3 gig. If you have 8 gig in your system, PostgreSQL
> won't be able to use it.
Depends on how it is done.
> I think threading connections is a VERY bad idea. I am dubious that the
> amount of work will result in a decent return on investment.
Depends on how it is done. We should be careful to assume that threading
postgresql instantly equates to threading connections. That is only *ONE*
possible type of threading architecture one could choose. Making broad
generalized statements doesn't accomplish anything in this debate ...
instead be more focused with your comments so one can make heads or tails
out of them.
--
//========================================================\\
|| D. Hageman <dhageman@dracken.com> ||
\\========================================================//
