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.
Agreed.
>
> 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.
>
Yes, but because the current file manager is built with three layers of
absraction OS FD --> Postgres Vfd --> Postgres Storage Manager it is
possible to manage and configure this very nicely. For threaded postgres,
each thread has its own storage manager which share Vfd's to sharing max.
This prevents too many threads from trying to seek on the same OS FD. The
Vfd's manage OS FD resources.
> 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.
>
You should be able to set up several processes in shared memory for the
db. 5 processes * 256 client threads per process = 1280 clients or
something like that.
> As I have said before, multithreading queries within a connection
> process would be pretty cool, on a low load server,
I think this would be possible now if I knew how to spin out subqueries
from the query tree.
Myron
mkscott@sacadia.com
