-
Notifications
You must be signed in to change notification settings - Fork 867
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Jdbc4ResultSet to cache Jdbc4ResultSetMetaData instances #1
Conversation
This dramatically improves performance with regards to metadata-intensive operations. The original motivation is that without caching, each call to a ResultSet.updateXXX method would retrieve a new instance of the metadata, causing an entire query to be run. If you update many columns in the same row, the cost came to be very expensive. Performance may improve in other workloads as well, but this has not been measured.
The same change needs to be made in Jdbc3ResultSet and Jdbc2ResultSet unless you can rework the implementation so the caching happens in AbstractJdbc2ResultSet and works for all support JDBC versions. |
Same description as immediately previous commit, but also fixes the Jdbc3(g) ResultSet implementations.
Added an additional commit implementing the requested functionality. I assume you mean Jdbc3gResultSet not Jdbc2ResultSet, as I did not find a concrete implementation of the Jdbc2ResultSet. |
I went with a slightly different approach of doing the caching in AbstractJdbc2ResultSet. |
I've faced slower performances since 9.1 driver version. The method implements a caching object in the AbstractJdbc2ResultSetMetaData. Has anybody else accountered this huge slow in performances ? |
Yes, can you send another pull so we can test it ? |
dave, What do you mean about a pull ? (I am new to Github sorry !) |
Hmmm.... clone the official repo to yours barring that send me your patch that applies to the current repo Dave Cramer On 27 May 2014 09:48, chrisfrenchy notifications@github.com wrote:
|
Ok ; I will do that |
This dramatically improves performance with regards to
metadata-intensive operations. The original motivation is that without
caching, each call to a ResultSet.updateXXX method would retrieve a new
instance of the metadata, causing an entire query to be run. If you
update many columns in the same row, the cost came to be very expensive.
Performance may improve in other workloads as well, but this has not been
measured.