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
|
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: