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

what is lslowing me down? JDBC or Postgresql itself?

From: jeff(at)amiel(dot)net (Jeff Amiel)
To: pgsql-jdbc(at)postgresql(dot)org
Subject: what is lslowing me down? JDBC or Postgresql itself?
Date: 2004-03-30 15:42:32
Message-ID: e368dd0e.0403300742.fc9345b@posting.google.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
java test program (running on windows box)

Program starts X threads.

Each thread does it's own classForName and has OWN connection
(autocommit is turned off)

inside each thread, they use a shared queue to perform work on 1000
items.  Each thread will only grab one item (and hence only work on
single row in table)

Each of the 1000 items requires the thread to perform:
	1 select for update (single row)
	5 select statements (not for update) on single row (uses
index...low/no cost..."select count(*) from table where id=2". 
Prepared statement...but do not pass in paremeter...hardcode the id
value)
	1 update statement (the one we selected for update)
	1 commit

I put timing logging around the 5 select statements section only
(after checking everything else)

When running a single thread....takes 0 milliseconds
(mostly...sometimes takes 16)
when running 10 threads...takes between 15 and 150 milliseconds.
when running 20 threads....takes between 15 and 250 milliseconds.


I clear the table and vacuum full between each test.

I have tweaked the postgresql.conf settings only slightly from the
default install (increased shared buffers some)


Why is this happening?  Is the jdbc driver the limiting factor?  Is it
the database?  Can anyone give me any suggestions to troubleshoot?

more info....

Postgresql 7.4 running on FreeBSD
jdbc driver version 74_213 

single table----

        Table "public.table"
 Column |     Type      | Modifiers
--------+---------------+-----------
 id     | integer       | not null
 data   | character(15) | not null
Indexes:
    "id" primary key, btree (id)
    "tableid" unique, btree (id)


populate initially with 1000 entries...


any help would be greatly appreciated.

Responses

pgsql-jdbc by date

Next:From: Dave CramerDate: 2004-03-30 19:52:51
Subject: Re: OutOfMemory
Previous:From: Dave CramerDate: 2004-03-30 13:29:11
Subject: Re: V3 protocol, batch statements and binary transfer

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