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

From Bruce Momjian
Subject Re: Re: JDBC Performance
Date
Msg-id 200010081937.PAA17730@candle.pha.pa.us
Whole thread Raw
In response to Re: Re: JDBC Performance  (Gunnar R|nning <gunnar@candleweb.no>)
Responses Re: Re: JDBC Performance  (Peter Mount <peter@retep.org.uk>)
List pgsql-general
Applied, and new files added.


> 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
>
> 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.
>
> 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 :
>
> http://www.candleweb.no/~gunnar/projects/pgsql/postgresql.jar.
>
>
> 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".
>
> Check the org/postgresql/jdbc2/FastResultSet.java in the tarball above to
> see the modified getInt() method.
>
> Regards,
>
>     Gunnar
>


--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-general by date:

Previous
From: Collin Peters
Date:
Subject: Re: SV: Postmaster startup problems
Next
From: Bruce Momjian
Date:
Subject: Re: alternative DB locations