X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E08BD9DC9F7 for ; Mon, 27 Mar 2006 12:32:31 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 02431-04 for ; Mon, 27 Mar 2006 12:32:30 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4D3509DC86B for ; Mon, 27 Mar 2006 12:32:29 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k2RGWSTY015056; Mon, 27 Mar 2006 11:32:28 -0500 (EST) To: Thomas Hallgren cc: Martijn van Oosterhout , PostgreSQL-development , PL/Java Development Subject: Re: Shared memory In-reply-to: <4428125D.7000707@tada.se> References: <4423CF32.3060406@tada.se> <20060324125851.GC8718@svana.org> <4427A8F1.3020009@tada.se> <14559.1143473507@sss.pgh.pa.us> <4428125D.7000707@tada.se> Comments: In-reply-to Thomas Hallgren message dated "Mon, 27 Mar 2006 18:27:09 +0200" Date: Mon, 27 Mar 2006 11:32:28 -0500 Message-ID: <15055.1143477148@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.114 required=5 tests=[AWL=0.114] X-Spam-Score: 0.114 X-Spam-Level: X-Archive-Number: 200603/1152 X-Sequence-Number: 81550 Thomas Hallgren writes: > Tom Lane wrote: >> It's only that much difference? Given all the other advantages of >> separating the JVM from the backends, I'd say you should gladly pay >> that price. >> > If I'm right, and the most common scenario is clients using connection pools, then it's very > likely that you don't get any advantages at all. Paying for nothing with a 440% increase in > calling time (at best) seems expensive :-) You are focused too narrowly on a few performance numbers. In my mind the primary advantage is that it will *work*. I do not actually believe that you'll ever get the embedded-JVM approach to production-grade reliability, because of the fundamental problems with threading, error processing, etc. regards, tom lane