Skip to content
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

Closed
wants to merge 2 commits into from
Closed

Conversation

stevenschlansker
Copy link
Contributor

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.

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.
@kjurka
Copy link
Member

kjurka commented Feb 9, 2012

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.

@ghost ghost assigned kjurka Feb 9, 2012
Same description as immediately previous commit, but
also fixes the Jdbc3(g) ResultSet implementations.
@stevenschlansker
Copy link
Contributor Author

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.

@kjurka
Copy link
Member

kjurka commented Feb 10, 2012

I went with a slightly different approach of doing the caching in AbstractJdbc2ResultSet.

@kjurka kjurka closed this Feb 10, 2012
@chrisfrenchy
Copy link

I've faced slower performances since 9.1 driver version.
After some investigations, I've found metadata caching has been changed, and I have introducted a new caching method allowing performances to be similar than of 9.0 driver version.

The method implements a caching object in the AbstractJdbc2ResultSetMetaData.

Has anybody else accountered this huge slow in performances ?
Is anybody interested in testing this caching ?

@davecramer
Copy link
Member

Yes, can you send another pull so we can test it ?

@chrisfrenchy
Copy link

dave,

What do you mean about a pull ? (I am new to Github sorry !)

@davecramer
Copy link
Member

Hmmm....

clone the official repo to yours
make a branch called caching or whatever
patch the code with your changes
push your changes to your repo
then you can create a pull request against the official repo

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:

dave,

What do you mean about a pull ? (I am new to Github sorry !)


Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-44278183
.

@chrisfrenchy
Copy link

Ok ; I will do that

imario42 referenced this pull request in Gordiychuk/pgjdbc Nov 24, 2015
@heiko-jakob heiko-jakob mentioned this pull request Mar 25, 2022
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants