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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html