From: Bruce Momjian Date: Wed, 28 May 2003 05:02:38 +0000 (+0000) Subject: Add to thread discussion. X-Git-Tag: REL7_4_BETA1~525 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=e5f19598e07e9a0fc0a5c0f18bfac1fe92d21fc5;p=postgresql Add to thread discussion. --- diff --git a/doc/TODO.detail/thread b/doc/TODO.detail/thread index 28b40bee69..794f3d1b3e 100644 --- a/doc/TODO.detail/thread +++ b/doc/TODO.detail/thread @@ -3937,3 +3937,564 @@ TIP 6: Have you searched our list archives? http://archives.postgresql.org +From pgsql-hackers-owner+M37860@postgresql.org Fri Apr 11 15:37:03 2003 +Return-path: +Received: from relay3.pgsql.com (relay3.pgsql.com [64.117.224.149]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id h3BJaxv13018 + for ; Fri, 11 Apr 2003 15:37:01 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by relay3.pgsql.com (Postfix) with ESMTP + id 3F9D0EA81E7; Fri, 11 Apr 2003 19:36:56 +0000 (GMT) +X-Original-To: pgsql-hackers@postgresql.org +Received: from spampd.localdomain (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with ESMTP id D27B2476036 + for ; Fri, 11 Apr 2003 15:35:32 -0400 (EDT) +Received: from mail1.ihs.com (mail1.ihs.com [170.207.70.222]) + by postgresql.org (Postfix) with ESMTP id 742DD475F5F + for ; Fri, 11 Apr 2003 15:35:31 -0400 (EDT) +Received: from css120.ihs.com (css120.ihs.com [170.207.105.120]) + by mail1.ihs.com (8.12.9/8.12.9) with ESMTP id h3BJZHRF027332; + Fri, 11 Apr 2003 13:35:17 -0600 (MDT) +Date: Fri, 11 Apr 2003 13:31:06 -0600 (MDT) +From: "scott.marlowe" +To: Ron Peacetree +cc: +Subject: Re: [HACKERS] Anyone working on better transaction locking? +In-Reply-To: +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-MailScanner: Found to be clean +X-Spam-Status: No, hits=-31.5 required=5.0 + tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, + QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE + autolearn=ham version=2.50 +X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +On Wed, 9 Apr 2003, Ron Peacetree wrote: + +> "Andrew Sullivan" wrote in message +> news:20030409170926.GH2255@libertyrms.info... +> > On Wed, Apr 09, 2003 at 05:41:06AM +0000, Ron Peacetree wrote: +> > Nonsense. You explicitly made the MVCC comparison with Oracle, and +> > are asking for a "better" locking mechanism without providing any +> > evidence that PostgreSQL's is bad. +> > +> Just because someone else's is "better" does not mean PostgreSQL's is +> "bad", and I've never said such. As I've said, I'll get back to Tom +> and the list on this. + +But you didn't identify HOW it was better. I think that's the point +being made. + +> > > Please see my posts with regards to ... +> > +> > I think your other posts were similar to the one which started this +> > thread: full of mighty big pronouncements which turned out to depend +> > on a bunch of not-so-tenable assumptions. +> > +> Hmmm. Well, I don't think of algorithm analysis by the likes of +> Knuth, Sedgewick, Gonnet, and Baeza-Yates as being "not so tenable +> assumptions", but YMMV. As for "mighty pronouncements", that also +> seems a bit misleading since we are talking about quantifiable +> programming and computer science issues, not unquantifiable things +> like politics. + +But the real truth is revealed when the rubber hits the pavement. +Remember that Linux Torvalds was roundly criticized for his choice of a +monolithic development model for his kernel, and was literally told that +his choice would restrict to "toy" status and that no commercial OS could +scale with a monolithic kernel. + +There's no shortage of people with good ideas, just people with the skills +to implement those good ideas. If you've got a patch to apply that's been +tested to show something is faster EVERYONE here wants to see it. + +If you've got a theory, no matter how well backed up by academic research, +it's still just a theory. Until someone writes to code to implement it, +the gains are theoretical, and many things that MIGHT help don't because +of the real world issues underlying your database, like I/O bandwidth or +CPU <-> memory bandwidth. + +> > I'm sorry to be so cranky about this, but I get tired of having to +> > defend one of my employer's core technologies from accusations based +> > on half-truths and "everybody knows" assumptions. For instance, +> > +> Again, "accusations" is a bit strong. I thought the discussion was +> about the technical merits and costs of various features and various +> ways to implement them, particularly when this product must compete +> for installed base with other solutions. Being coldly realistic about +> what a product's strengths and weaknesses are is, again, just good +> business. Sun Tzu's comment about knowing the enemy and yourself +> seems appropriate here... + +No, you're wrong. Postgresql doesn't have to compete. It doesn't have to +win. it doesn't need a marketing department. All those things are nice, +and I'm glad if it does them, but doesn't HAVE TO. Postgresql has to +work. It does that well. + +Postgresql CAN compete if someone wants to put the effort into competing, +but it isn't a priority for me. Working is the priority, and if other +people aren't smart enough to test Postgresql to see if it works for them, +all the better, I keep my edge by having a near zero cost database engine, +while the competition spends money on MSSQL or Oracle. + +Tom and Andrew ARE coldly realistic about the shortcomings of postgresql. +It has issues, and things that need to be fixed. It needs more coders. +It doesn't need every feature that Oracle or DB2 have. Heck some of their +"features" would be considered a mis-feature in the Postgresql world. + +> > > I'll mention thread support in passing, +> > +> > there's actually a FAQ item about thread support, because in the +> > opinion of those who have looked at it, the cost is just not worth +> > the benefit. If you have evidence to the contrary (specific +> > evidence, please, for this application), and have already read all +> the +> > previous discussion of the topic, perhaps people would be interested +> in +> > opening that debate again (though I have my doubts). +> > +> Zeus had a performance ceiling roughly 3x that of Apache when Zeus +> supported threading as well as pre-forking and Apache only supported +> pre forking. The Apache folks now support both. DB2, Oracle, and SQL +> Server all use threads. Etc, etc. + +Yes, and if you configured your apache server to have 20 or 30 spare +servers, in the real world, it was nearly neck and neck to Zeus, but since +Zeus cost like $3,000 a copy, it is still cheaper to just overwhelm it +with more servers running apache than to use zeus. + +> That's an awful lot of very bright programmers and some serious $$ +> voting that threads are worth it. + +For THAT application. for what a web server does, threads can be very +useful, even useful enough to put up with the problems created by running +threads on multiple threading libs on different OSes. + +Let me ask you, if Zeus scrams and crashes out, and it's installed +properly so it just comes right back up, how much data can you lose? + +If Postgresql scrams and crashes out, how much data can you lost? + +> Given all that, if PostgreSQL +> specific +> thread support is =not= showing itself to be a win that's an +> unexpected +> enough outcome that we should be asking hard questions as to why not. + +There HAS been testing on threads in Postgresql. It has been covered to +death. The fact that you're still arguing proves you likely haven't read +the archive (google has it back to way back when, use that to look it up) +about this subject. + +Threads COULD help on multi-sorted results, and a few other areas, but the +increase in performance really wasn't that great for 95% of all the cases, +and for the 5% it was, simple query planner improvements have provided far +greater performance increases. + +The problem with threading is that we can either use the one process -> +many thread design, which I personally don't trust for something like a +database, or a process per backend connection which can run +multi-threaded. This scenario makes Postgresql just as stable and +reliable as it was as a multi-process app, but allows threaded performance +in certain areas of the backend that are parallelizable to run in parallel +on multi-CPU systems. + +the gain, again, is minimal, and on a system with many users accessing it, +there is NO real world gain. + +> At their core, threads are a context switching efficiency tweak. + +Except that on the two OSes which Postgresql runs on the most, threads are +really no faster than processes. In the Linux kernel, the only real +difference is how the OS treats them, creation, destruction of threads +versus processes is virtually identical there. + +> Certainly it's =possible= that threads have nothing to offer +> PostgreSQL, but IMHO it's not =probable=. Just another thing for me +> to add to my TODO heap for looking at... + +It's been tested, it didn't help a lot, and it made it MUCH harder to +maintain, as threads in Linux are handled by a different lib than in say +Solaris, or Windows or any other OS. I.e. you can't guarantee the thread +lib you need will be there, and that there are no bugs. MySQL still has +thread bug issues pop up, most of which are in the thread libs themselves. + + +---------------------------(end of broadcast)--------------------------- +TIP 4: Don't 'kill -9' the postmaster + +From pgsql-hackers-owner+M37865@postgresql.org Fri Apr 11 17:34:21 2003 +Return-path: +Received: from relay1.pgsql.com (relay1.pgsql.com [64.49.215.129]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id h3BLYIv28485 + for ; Fri, 11 Apr 2003 17:34:19 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by relay1.pgsql.com (Postfix) with ESMTP + id 0AF036F77ED; Fri, 11 Apr 2003 17:34:19 -0400 (EDT) +X-Original-To: pgsql-hackers@postgresql.org +Received: from spampd.localdomain (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with ESMTP id EBB41476323 + for ; Fri, 11 Apr 2003 17:33:02 -0400 (EDT) +Received: from filer (12-234-86-219.client.attbi.com [12.234.86.219]) + by postgresql.org (Postfix) with ESMTP id CED7D4762E1 + for ; Fri, 11 Apr 2003 17:32:57 -0400 (EDT) +Received: from localhost (localhost [127.0.0.1]) + (uid 1000) + by filer with local; Fri, 11 Apr 2003 14:32:59 -0700 +Date: Fri, 11 Apr 2003 14:32:59 -0700 +From: Kevin Brown +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Anyone working on better transaction locking? +Message-ID: <20030411213259.GU1833@filer> +Mail-Followup-To: Kevin Brown , + pgsql-hackers@postgresql.org +References: <20030409170926.GH2255@libertyrms.info> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +In-Reply-To: +User-Agent: Mutt/1.4i +Organization: Frobozzco International +X-Spam-Status: No, hits=-38.0 required=5.0 + tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, + REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT + autolearn=ham version=2.50 +X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Ron Peacetree wrote: +> Zeus had a performance ceiling roughly 3x that of Apache when Zeus +> supported threading as well as pre-forking and Apache only supported +> pre forking. The Apache folks now support both. DB2, Oracle, and SQL +> Server all use threads. Etc, etc. + +You can't use Apache as an example of why you should thread a database +engine, except for the cases where the database is used much like the +web server is: for numerous short transactions. + +> That's an awful lot of very bright programmers and some serious $$ +> voting that threads are worth it. Given all that, if PostgreSQL +> specific thread support is =not= showing itself to be a win that's +> an unexpected enough outcome that we should be asking hard questions +> as to why not. + +It's not that there won't be any performance benefits to be had from +threading (there surely will, on some platforms), but gaining those +benefits comes at a very high development and maintenance cost. You +lose a *lot* of robustness when all of your threads share the same +memory space, and make yourself vulnerable to classes of failures that +simply don't happen when you don't have shared memory space. + +PostgreSQL is a compromise in this regard: it *does* share memory, but +it only shares memory that has to be shared, and nothing else. To get +the benefits of full-fledged threads, though, requires that all memory +be shared (otherwise the OS has to tweak the page tables whenever it +switches contexts between your threads). + +> At their core, threads are a context switching efficiency tweak. + +This is the heart of the matter. Context switching is an operating +system problem, and *that* is where the optimization belongs. Threads +exist in large part because operating system vendors didn't bother to +do a good job of optimizing process context switching and +creation/destruction. + +Under Linux, from what I've read, process creation/destruction and +context switching happens almost as fast as thread context switching +on other operating systems (Windows in particular, if I'm not +mistaken). + +> Since DB's switch context a lot under many circumstances, threads +> should be a win under such circumstances. At the least, it should be +> helpful in situations where we have multiple CPUs to split query +> execution between. + +This is true, but I see little reason that we can't do the same thing +using fork()ed processes and shared memory instead. + +There is context switching within databases, to be sure, but I think +you'll be hard pressed to demonstrate that it is anything more than an +insignificant fraction of the total overhead incurred by the database. +I strongly suspect that much larger gains are to be had by optimizing +other areas of the database, such as the planner, the storage manager +(using mmap for file handling may prove useful here), the shared +memory system (mmap may be faster than System V style shared memory), +etc. + +The big overhead in the process model on most platforms is in creation +and destruction of processes. PostgreSQL has a relatively high +connection startup cost. But there are ways of dealing with this +problem other than threading, namely the use of a connection caching +middleware layer. Such layers exist for databases other than +PostgreSQL, so the high cost of fielding and setting up a database +connection is *not* unique to PostgreSQL ... which suggests that while +threading may help, it doesn't help *enough*. + +I'd rather see some development work go into a connection caching +process that understands the PostgreSQL wire protocol well enough to +look like a PostgreSQL backend to connecting processes, rather than +see a much larger amount of effort be spent on converting PostgreSQL +to a threaded architecture (and then discover that connection caching +is still needed anyway). + +> Certainly it's =possible= that threads have nothing to offer +> PostgreSQL, but IMHO it's not =probable=. Just another thing for me +> to add to my TODO heap for looking at... + +It's not that threads don't have anything to offer. It's that the +costs associated with them are high enough that it's not at all clear +that they're an overall win. + + +-- +Kevin Brown kevin@sysexperts.com + + +---------------------------(end of broadcast)--------------------------- +TIP 6: Have you searched our list archives? + +http://archives.postgresql.org + +From pgsql-hackers-owner+M37876@postgresql.org Sat Apr 12 06:56:17 2003 +Return-path: +Received: from relay3.pgsql.com (relay3.pgsql.com [64.117.224.149]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id h3CAuDS20700 + for ; Sat, 12 Apr 2003 06:56:15 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by relay3.pgsql.com (Postfix) with ESMTP + id 35797EA81FF; Sat, 12 Apr 2003 10:55:59 +0000 (GMT) +X-Original-To: pgsql-hackers@postgresql.org +Received: from spampd.localdomain (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with ESMTP id 7393E4762EF + for ; Sat, 12 Apr 2003 06:54:48 -0400 (EDT) +Received: from filer (12-234-86-219.client.attbi.com [12.234.86.219]) + by postgresql.org (Postfix) with ESMTP id 423294762E1 + for ; Sat, 12 Apr 2003 06:54:44 -0400 (EDT) +Received: from localhost (localhost [127.0.0.1]) + (uid 1000) + by filer with local; Sat, 12 Apr 2003 03:54:52 -0700 +Date: Sat, 12 Apr 2003 03:54:52 -0700 +From: Kevin Brown +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Anyone working on better transaction locking? +Message-ID: <20030412105452.GV1833@filer> +Mail-Followup-To: Kevin Brown , + pgsql-hackers@postgresql.org +References: <20030409170926.GH2255@libertyrms.info> <20030411213259.GU1833@filer> <200304121221.12377.shridhar_daithankar@nospam.persistent.co.in> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +In-Reply-To: <200304121221.12377.shridhar_daithankar@nospam.persistent.co.in> +User-Agent: Mutt/1.4i +Organization: Frobozzco International +X-Spam-Status: No, hits=-39.4 required=5.0 + tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, + QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT + autolearn=ham version=2.50 +X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Shridhar Daithankar wrote: +> Apache does too many things to be a speed daemon and what it offers +> is pretty impressive from performance POV. +> +> But database is not webserver. It is not suppose to handle tons of +> concurrent requests. That is a fundamental difference. + +I'm not sure I necessarily agree with this. A database is just a +tool, a means of reliably storing information in such a way that it +can be retrieved quickly. Whether or not it "should" handle lots of +concurrent requests is a question that the person trying to use it +must answer. + +A better answer is that a database engine that can handle lots of +concurrent requests can also handle a smaller number, but not vice +versa. So it's clearly an advantage to have a database engine that +can handle lots of concurrent requests because such an engine can be +applied to a larger number of problems. That is, of course, assuming +that all other things are equal... + +There are situations in which a database would have to handle a lot of +concurrent requests. Handling ATM transactions over a large area is +one such situation. A database with current weather information might +be another, if it is actively queried by clients all over the country. +Acting as a mail store for a large organization is another. And, of +course, acting as a filesystem is definitely another. :-) + +> Well. Threading does not necessarily imply one thread per connection +> model. Threading can be used to make CPU work during I/O and taking +> advantage of SMP for things like sort etc. This is especially true +> for 2.4.x linux kernels where async I/O can not be used for threaded +> apps. as threads and signal do not mix together well. + +This is true, but whether you choose to limit the use of threads to a +few specific situations or use them throughout the database, the +dangers and difficulties faced by the developers when using threads +will be the same. + +> One connection per thread is not a good model for postgresql since +> it has already built a robust product around process paradigm. If I +> have to start a new database project today, a mix of process+thread +> is what I would choose bu postgresql is not in same stage of life. + +Certainly there are situations for which it would be advantageous to +have multiple concurrent actions happening on behalf of a single +connection, as you say. But that doesn't automatically mean that a +thread is the best overall solution. On systems such as Linux that +have fast process handling, processes are almost certainly the way to +go. On other systems such as Solaris or Windows, threads might be the +right answer (on Windows they might be the *only* answer). But my +argument here is simple: the responsibility of optimizing process +handling belongs to the maintainers of the OS. Application developers +shouldn't have to worry about this stuff. + +Of course, back here in the real world they *do* have to worry about +this stuff, and that's why it's important to quantify the problem. +It's not sufficient to say that "processes are slow and threads are +fast". Processes on the target platform may well be slow relative to +other systems (and relative to threads). But the question is: for the +problem being solved, how much overhead does process handling +represent relative to the total amount of overhead the solution itself +incurs? + +For instance, if we're talking about addressing the problem of +distributing sorts across multiple CPUs, the amount of overhead +involved in doing disk activity while sorting could easily swamp, in +the typical case, the overhead involved in creating parallel processes +to do the sorts themselves. And if that's the case, you may as well +gain the benefits of using full-fledged processes rather than deal +with the problems that come with the use of threads -- because the +gains to be found by using threads will be small in relative terms. + +> > > At their core, threads are a context switching efficiency tweak. +> > +> > This is the heart of the matter. Context switching is an operating +> > system problem, and *that* is where the optimization belongs. Threads +> > exist in large part because operating system vendors didn't bother to +> > do a good job of optimizing process context switching and +> > creation/destruction. +> +> But why would a database need a tons of context switches if it is +> not supposed to service loads to request simaltenously? If there are +> 50 concurrent connections, how much context switching overhead is +> involved regardless of amount of work done in a single connection? +> Remeber that database state is maintened in shared memory. It does +> not take a context switch to access it. + +If there are 50 concurrent connections with one process per +connection, then there are 50 database processes. The context switch +overhead is incurred whenever the current process blocks (or exhausts +its time slice) and the OS activates a different process. Since +database handling is generally rather I/O intensive as services go, +relatively few of those 50 processes are likely to be in a runnable +state, so I would expect the overall hit from context switching to be +rather low -- I'd expect the I/O subsystem to fall over well before +context switching became a real issue. + +Of course, all of that is independent of whether or not the database +can handle a lot of simultaneous requests. + +> > Under Linux, from what I've read, process creation/destruction and +> > context switching happens almost as fast as thread context switching +> > on other operating systems (Windows in particular, if I'm not +> > mistaken). +> +> I hear solaris also has very heavy processes. But postgresql has +> other issues with solaris as well. + +Yeah, I didn't want to mention Solaris because I haven't kept up with +it and thought that perhaps they had fixed this... + + +-- +Kevin Brown kevin@sysexperts.com + + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M37883@postgresql.org Sat Apr 12 16:09:19 2003 +Return-path: +Received: from relay1.pgsql.com (relay1.pgsql.com [64.49.215.129]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id h3CK9HS03520 + for ; Sat, 12 Apr 2003 16:09:18 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by relay1.pgsql.com (Postfix) with ESMTP + id 507626F768B; Sat, 12 Apr 2003 16:09:01 -0400 (EDT) +X-Original-To: pgsql-hackers@postgresql.org +Received: from spampd.localdomain (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with ESMTP id 06543475AE4 + for ; Sat, 12 Apr 2003 16:08:03 -0400 (EDT) +Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) + by postgresql.org (Postfix) with SMTP id C6DC347580B + for ; Sat, 12 Apr 2003 16:08:01 -0400 (EDT) +Received: (qmail 31386 invoked by uid 65534); 12 Apr 2003 20:08:13 -0000 +Received: from chello062178186201.1.15.tuwien.teleweb.at (EHLO beeblebrox) (62.178.186.201) + by mail.gmx.net (mp001-rz3) with SMTP; 12 Apr 2003 22:08:13 +0200 +Message-ID: <01cc01c3012f$526aaf80$3201a8c0@beeblebrox> +From: "Michael Paesold" +To: "Neil Conway" , "Kevin Brown" +cc: "PostgreSQL Hackers" +References: <20030409170926.GH2255@libertyrms.info> <20030411213259.GU1833@filer> <1050175777.392.13.camel@tokyo> +Subject: Re: [HACKERS] Anyone working on better transaction locking? +Date: Sat, 12 Apr 2003 22:08:40 +0200 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="Windows-1252" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 6.00.2800.1106 +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 +X-Spam-Status: No, hits=-25.8 required=5.0 + tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, + REPLY_WITH_QUOTES + autolearn=ham version=2.50 +X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Neil Conway wrote: + +> Furthermore, IIRC PostgreSQL's relatively slow connection creation time +> has as much to do with other per-backend initialization work as it does +> with the time to actually fork() a new backend. If there is interest in +> optimizing backend startup time, my guess would be that there is plenty +> of room for improvement without requiring the replacement of processes +> with threads. + +I see there is a whole TODO Chapter devoted to the topic. There is the idea +of pre-forked and persistent backends. That would be very useful in an +environment where it's quite hard to use connection pooling. We are +currently working on a mail system for a free webmail. The mda (mail +delivery agent) written in C connects to the pg database to do some queries +everytime a new mail comes in. I didn't find a solution for connection +pooling yet. + +About the TODO items, apache has a nice description of their accept() +serialization: +http://httpd.apache.org/docs-2.0/misc/perf-tuning.html + +Perhaps this could be useful if someone decided to start implementing those +features. + +Regards, +Michael Paesold + + +---------------------------(end of broadcast)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org +