Re: measure of JDBC performances

From: Kovács Péter <peter(dot)kovacs(at)sysdata(dot)siemens(dot)hu>
To: "'Auri Mason'" <amason(at)syntrex(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: measure of JDBC performances
Date: 2002-03-14 13:58:59
Message-ID: 8A2DDD7ED7876A4698F6FF204F62CBFC11DE7F@budg112a.sysdata.siemens.hu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Hi Auri,

>>(1) by the specific way your Java server tier uses the JDBC connection
>Could you explain me exactly what you mean?

Though the jdbc API itself is fairly unabiguous, the implementations differ
slightly from vendor to vendor. For example, the clear intent of the API
designer was that result sets should use cursors (see
ResultSet.getCursorName). However, last time I checked many of the vendors
have not used cursors for selects, because their cursors can only be moved
forward and so the methods of the ResultSet class implying backward movement
could not have been implemented. Even PGSQL's JDBC driver uses client side
caching of the full result set instead of cursors, although the PGSQL cursor
supports backward movements.

So implementations of different vendors may differ not only between
themselves, but also from what behaviour/implementation you would
instinctively expect based on the API. If your application relies on a
relatively large amount of persistency logic (such as container managed
persistency for EJBs) implemented in the "java tier" you use (application
server or equivalent), your application may indirectly use generic code
(driving the JDBC driver), which is not necessarily aware of the subtle
differences between JDBC driver implementations. In this case, the java tier
contains built-in assumptions about the behaviour of the JDBC driver, which
may hold for most of the JDBC driver implementations, but may not hold for
certain implementations resulting in substantial performance degradation.

But this is pure speculation, because I do not know (and probably never will
:-)) how exactly you use the JDBC driver.

Peter

-----Original Message-----
From: Auri Mason [mailto:amason(at)syntrex(dot)com]
Sent: Wednesday, March 13, 2002 12:49 PM
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] measure of JDBC performances

Hi again Peter,

Thx for you feedback/opinion,

> It is not a wrong idea at all, but I do not think the difference between
the
> performance of psql and JDBC should be significant.

My first idea was that the JDBC were the cause of low performances...

> and I found that PostgreSQL was the second best just a bit behind
Interbase

Yeah, good news! This was the result as I'm aspecting!

> So my guess would be, that the observed huge performance gap between MS
SQL
> and PostgreSQL can be explained either
>(1) by the specific way your Java server tier uses the JDBC connection
Could you explain me exactly what you mean?

>(2) some indexing problem
I'll check this ASAP!

THX, Auri

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

Browse pgsql-jdbc by date

  From Date Subject
Next Message Doug McNaught 2002-03-14 16:05:08 Re: [HACKERS] problems with Tomcat and postgres
Previous Message Dave Cramer 2002-03-14 12:57:43 Re: [GENERAL] JDBC-Question