On Wed, 16 Oct 2002, Bruce Momjian wrote:
> It may be optional some day, most likely for Win32 at first, but we see
> little value to it on most other platforms; of course, we may be wrong.
> I am also not sure if it is a big win on Apache either; I think the
> jury is still out on that one, hence the slow adoption of 2.X, and we
> don't want to add threads and make a mess of the code or slow it down,
> which does often happen.
Actually, Apache2 is both multi-process and multi-thread, even in the
'multi-thread' model ... I've played a bit with it, and it works at a
sort of 'half way point' taking advantage of advantages of both ... in
fact, I really wish someone would look at it seriously, since it mimics
alot of what we do to start with ...
old apache - one parent process (ie. postmaster) with child process (ie. postgres) actually handling the
work
new apache - one parent process (ie. postmaster) with child processes (ie. postgres) actually handling the
work,with a twist .. each child process can handle x threaded processes
so, in a heavily loaded web server, you might see 10 httpd processes
running, each of which handling 15 threaded connections ...
even getting away from multiple db connections per child process, I could
see some other areas where multi-threading could be useful, assuming that
my limited knowleddge of threading is remotely correct ... a big/cool one
could be:
distributed/clustered databases
a database could be setup on multiple servers, where the tables
are created as 'CREATE TABLE newtable ON SERVER serverb', so that when you
connect to that table, the child process knows to auto-matically establish
connections to the remote servers to pull data in
this would also work for inter-database queries, that several ppl
in the past have asked for
