Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads - Mailing list pgsql-jdbc

From Steven Schlansker
Subject Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
Date
Msg-id 20279E38-EDB7-4D2B-8DD1-A1CF5F3E9F1D@likeness.com
Whole thread Raw
In response to Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads  (Till Toenges <tt@kyon.de>)
List pgsql-jdbc
On Feb 9, 2012, at 6:59 PM, Dave Cramer wrote:

> Steven,
>
> I think this http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
> applies to your implementation ?
>

Hi,

I'm not sure how locking applies here.  There is no locking code that I see in any of the ResultSet classes, nor did I
addany, and it's my understanding that ResultSet instances themselves are not to be shared amongst threads.  So this is
notrelevant. 

Let me know if I've misunderstood,
Steven

>
>
> On Thu, Feb 9, 2012 at 7:01 PM, Steven Schlansker <steven@likeness.com> wrote:
>> Hi,
>>
>> There is a bug report and associated mailing list thread
>> [JDBC] [BUGS] BUG #6293: JDBC driver performance, dated Nov 15 2011
>>
>>>>>
>>>>> The following bug has been logged online:
>>>>>
>>>>> Bug reference:      6293
>>>>> PostgreSQL version: 9.1
>>>>> Description:        JDBC driver performance
>>>>> Details:
>>>>
>>>> The 9.1 JDBC driver was changed to try and fetch all metadata for the
>>>> entire resultset in one query instead of potentially issuing multiple
>>>> queries for each column.  So this change was supposed to improve things.
>>>>
>>>> Looking at the code, the caching pattern has changed slightly, so now it's
>>>> important to hold onto the same ResultSetMetaData instance.  That is you
>>>> need to do:
>>
>> I have a proposed fix available as a pull request on GitHub.  The commit itself is here:
>> https://github.com/NessComputing/pgjdbc/commit/15dee25198c0a7a4d3bdeca2193a003d552fac2f
>>
>> and the pull request complete with an in-progress discussion is here:
>> https://github.com/pgjdbc/pgjdbc/pull/1
>>
>> I requested guidance on the mailing list last week on the best way to approach this problem,
>> but there were no responses, so I have changed the ResultSet to cache the MetaData instances.
>>
>> As best as I can tell the MetaData is immutable, so hopefully there will be no ill effects from
>> caching instances.
>>
>> I saw some discussion about licensing re: GitHub on the mailing list the other day, so to be
>> perfectly clear I am releasing this code to the pgsql-jdbc project under whatever terms they
>> so choose, or the public domain if that is the appropriate choice.
>>
>> I hope this will be an example of how moving to GitHub pull requests can be a positive change :-)
>>
>>
>> I believe this fixes the referenced bug, and I've asked the original submitter to test out my change
>> to see if it fixes it for him.
>>
>> Regards,
>> Steven Schlansker
>> Ness Computing
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc


pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
Next
From: Till Toenges
Date:
Subject: Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads