X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 1455052B75 for ; Tue, 26 Jul 2005 22:33:42 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 84663-09 for ; Wed, 27 Jul 2005 01:33:38 +0000 (GMT) Received: from isis.sigpipe.cz (fw.sigpipe.cz [62.245.70.224]) by svr1.postgresql.org (Postfix) with ESMTP id 3747452C2B for ; Tue, 26 Jul 2005 22:33:34 -0300 (ADT) Received: by isis.sigpipe.cz (Postfix, from userid 1001) id BF0691F87BEF; Wed, 27 Jul 2005 03:33:38 +0200 (CEST) Date: Wed, 27 Jul 2005 03:33:38 +0200 From: Roman Neuhauser To: Halley Pacheco de Oliveira Cc: pgsql-docs@postgresql.org Subject: Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Message-ID: <20050727013338.GB426@isis.sigpipe.cz> Mail-Followup-To: Halley Pacheco de Oliveira , pgsql-docs@postgresql.org References: <20050726194901.GA56282@isis.sigpipe.cz> <20050727011712.64392.qmail@web52709.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050727011712.64392.qmail@web52709.mail.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.349 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: * X-Archive-Number: 200507/30 X-Sequence-Number: 3156 # halleypo@yahoo.com.br / 2005-07-26 22:17:12 -0300: > --- Roman Neuhauser escreveu: > > But maybe I'm not understanding the point you're trying to make. > > To make things a bit clearer: what is it that you find so disturbing > > or surprising in the current PostgreSQL behavior? Why did you expect > > it reusing the same process, and what benefits do you expect (or > > preferably, have experimentally gained) from the alternative? > > The surprise is: > > Oracle - MTS - Multi-Threaded-Server - MTS allows many user processes > to share very few server processes. Without MTS, each user process > requires its own dedicated server process; a new server process is > created for each client requesting a connection. A dedicated server > process remains associated to the user process for the remainder of > the connection. With MTS many user processes connect to a dispatcher > process. The dispatcher routes client requests to the next available > shared server process. The advantage of MTS is that system overhead is > reduced, so the number of users that can be supported is increased. I came to PostgreSQL from MySQL, which is multithreaded, and found PostgreSQL absolutely UNsurprising in this aspect. There's quite a few populare programs that behave similarly. > Contrasting with this in PostgreSQL a new process is forked just to > connect to another database. The PostgreSQL behavior seems similar to > old Oracle versions. So what? Is this a troll? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991