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

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group