Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads
От | Steven Schlansker |
---|---|
Тема | Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads |
Дата | |
Msg-id | 20279E38-EDB7-4D2B-8DD1-A1CF5F3E9F1D@likeness.com обсуждение исходный текст |
Ответ на | Re: Patch to fix bug #6293 - regression in driver performance with regards to ResultSetMetaData-heavy workloads (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Patch to fix bug #6293 - regression in driver performance
with regards to ResultSetMetaData-heavy workloads
|
Список | 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 по дате отправления: