Re: Calling conventions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Matthew Wakeling" <matthew(at)flymine(dot)org>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Calling conventions
Date: 2009-07-20 21:03:44
Message-ID: 4A64956002000025000289D9@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Matthew Wakeling <matthew(at)flymine(dot)org> wrote:

> On Fri, 17 Jul 2009, Kevin Grittner wrote:

>> but a factor of 100?

> The Java code runs all in RAM, versus Postgres running all from OS
> cache or Postgres shared buffer (bit hard to tell which of those
> two it is - there is no hard drive activity anyway). The Java code
> does no page locking, whereas Postgres does loads. The Java code is
> emulating just the index, whereas Postgres is fetching the whole row
> as well.

Oh, well, if you load all the data into Java's heap and are accessing
it through HashMap or similar, I guess a factor of 100 is about right.
I see the big difference as the fact that the Java implementation is
dealing with everything already set up in RAM, versus needing to deal
with a "disk image" format, even if it is cached. Try serializing
those Java objects to disk and storing the file name in the HashMap,
retrieving and de-serializing the object for each reference. Even if
it's all cached, I expect you'd be running about 100 times slower.

The Java heap isn't a very safe place to persist long-term data,
however.

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2009-07-20 21:24:57 Re: Fastest char datatype
Previous Message Krade 2009-07-20 20:48:54 Re: Full text search with ORDER BY performance issue