Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Shared memory


  • From: Thomas Hallgren <thomas(at)tada(dot)se>
  • To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PL/Java Development <Pljava-dev(at)gborg(dot)postgresql(dot)org>
  • Subject: Re: Shared memory
  • Date: Mon, 27 Mar 2006 20:09:44 +0200
  • Message-id: <44282A68(dot)7030208(at)tada(dot)se>

Tom Lane wrote:
Thomas Hallgren <thomas(at)tada(dot)se> 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.
My focus with PL/Java over the last year has been to make it a production-grade product and I think I've succeeded pretty well. The current list of open bugs is second to none. What fundamental problems are you thinking of that hasn't been solved already?

Regards,
Thomas Hallgren




Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group