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 EB03A9DD89A for ; Tue, 28 Mar 2006 06:24:14 -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 91701-06 for ; Tue, 28 Mar 2006 06:24:16 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by postgresql.org (Postfix) with ESMTP id 326D99DD894 for ; Tue, 28 Mar 2006 06:24:06 -0400 (AST) Received: from [192.168.0.5] (unknown [84.12.26.47]) by smtp.nildram.co.uk (Postfix) with ESMTP id D296733985E; Tue, 28 Mar 2006 11:24:05 +0100 (BST) Subject: Re: Shared memory From: Simon Riggs To: Thomas Hallgren Cc: Tom Lane , Martijn van Oosterhout , PostgreSQL-development , PL/Java Development 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> Content-Type: text/plain Date: Tue, 28 Mar 2006 11:23:59 +0100 Message-Id: <1143541439.3839.323.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.097 required=5 tests=[AWL=0.097] X-Spam-Score: 0.097 X-Spam-Level: X-Archive-Number: 200603/1172 X-Sequence-Number: 81570 On Mon, 2006-03-27 at 18:27 +0200, Thomas Hallgren wrote: > 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 :-) Just some thoughts from afar: DB2 supports in-process and out-of-process external function calls (UDFs) that it refers to as UNFENCED and FENCED procedures. For Java only, IBM have moved to supporting *only* FENCED procedures for Java functions, i.e. having a single JVM for all connections. Each connection's Java function runs as a thread on a single dedicated JVM-only process. That approach definitely does increase the invocation time, but it significantly reduces the resources associated with the JVM, as well as allowing memory management to be more controllable (bliss...). So the overall picture could be more CPU and memory resources for each connection in the connection pool. If you have a few small Java functions centralisation would not be good, but if you have a whole application architecture with many connections executing reasonable chunks of code then this can be a win. In that environment we used Java for major database functions, with SQL functions for small extensions. Also the Java invocation time we should be celebrating is that by having Java in the database the Java<->DB time is much less than it would be if we had a Java stack sitting on another server. Best Regards, Simon Riggs