Re: Re: JDBC Performance - Mailing list pgsql-general

On 5 Oct 2000, Gunnar R|nning wrote:

> Peter Mount <peter@retep.org.uk> writes:
>
> >
> > Anything of this nature always does.
> >
>
> Okay, I have some new code in place that hopefully should work better. I
> couldn't produce a full patch using cvs diff -c this time since I have
> created new files and anonymous cvs usage doesn't allow you to
> adds. I'm supplying the modified src/interfaces/jdbc as a tarball at :
> http://www.candleweb.no/~gunnar/projects/pgsql/postgres-jdbc-2000-10-05.tgz

Got it. Don't worry about the diff, I'll merge it in manually. At this
stage, it will be easier, and less prone to generating bugs with the
changes I've got here.

> The new files that should be added are :
>
> ? org/postgresql/PGStatement.java
> ? org/postgresql/ObjectPool.java
> ? org/postgresql/ObjectPoolFactory.java
>
> There is now a global static pool of free byte arrays and used byte arrays
> connected to a statement object. This is the role of the new PGStatement
> class. Access to the global free array is synchronized, while we rely on
> the PG_Stream synchronization for the used array.

Good. That should keep the thread safety intact.

> My measurements show that the perfomance boost on this code is not quite as
> big as my last shot, but it is still an improvement. Maybe some of the
> difference is due to the new synchronization on the global array. I think I
> will look into choosing between on a connection level and global level.
>
>
> I would also appreciate it if anybody would test the new driver. My test
> platform is RedHat Linux 6.2, and since the effect of these changes could
> be very dependent on the actual platform and JVM tests from other platforms
> would be very nice to see. I have a precompiled version at :

SuSE 6.4 (got 7.0 to install shortly). As soon as I recover my VMWare
licence, I'll be able to get the other OS's up and running as well.

> I have also started experimented with improving the performance of the
> various conversions. The problem here is ofcourse related handle the
> various encodings. One thing I found to speed up ResultSet.getInt() a lot
> was to do custom conversion on the byte array into int instead of going
> through the getString() to do the conversion. But I'm unsure if this is
> portable, can we assume that a digit never can be represented by more than
> one byte ? It works fine in my iso-latin-8859-1 environment, but what about
> other environments ? Maybe we could provide different ResultSet
> implementations depending on the encoding used or delegate some methods of
> the result set to an "converter class".

We would have to have a rethink on how ResultSet is implemented.

Currently we have a common parent class org.postgresql.ResultSet which is
common to both jdbc1 & jdbc2 drivers. However, this class is abstract
because we then extend it for each of the two drivers because of the extra
methods.

However, remember I'm planning implementing Scrollable ResultSet's. I was
going to do it by splitting the org.postgresql.jdbc2.ResultSet class,
two, one for the current non-scrollable version, and one for the
scrollable one.

ie:

org.postgresql.ResultSet -+--> org.postgresql.jdbc1.ResultSet (JDBC1 only)
                          |
                          |
           org.postgresql.jdbc2.ResultSet    (JDBC2 only, common
                          |                    conversions here)
                          |
            +-------------+------------------------+
            |                                      |
   org.postgresql.jdbc2.NSResultSet  org.postgresql.jdbc2.ScrResultSet

   Current Non Scrollable ResultSet  New Scrollable ResultSet Implementation

Now the conversion stuff would have to go in the org.postgresql.ResultSet
class if it's to be used in both drivers, or in
org.postgresql.jdbc2.ResultSet class for jdbc2 only.

The problem I don't want to see is having conversion code duplicated,
which we still have in places, ResultSet being a good example.

Does this make sense?

> Check the org/postgresql/jdbc2/FastResultSet.java in the tarball above to
> see the modified getInt() method.

Will do.

PS: Sorry for the late reply, but my illness has knocked me out for the
last few days, so I've only just got to sit down to read my mail.

Peter

--
Peter T Mount peter@retep.org.uk http://www.retep.org.uk
PostgreSQL JDBC Driver http://www.retep.org.uk/postgres/
Java PDF Generator http://www.retep.org.uk/pdf/