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

Speed up connection creation on 9.0+ #144

Merged
merged 1 commit into from Apr 25, 2014

Conversation

Projects
None yet
3 participants
@sehrope
Contributor

sehrope commented Apr 18, 2014

After startup the JDBC driver checks the server version and if it's 9.0+ it sets the extra_float_digits and optionally the application_name. Setting each of these requires a couple of round trips as each is executed in its own SET foo = 'bar' statement.

If you know the remote server is 9.0+ then you can instead send both properties in the StartupMessage itself.

This patch adds a property to instruct the driver that the server you are connecting to is a "modern server", i.e. 9.0+. For lack of a better name I've called the property isModernServer. If set to "true" then it will assume the remote server is 9.0+ and set the properties in the StartupMessage. Otherwise it'll function as it has in the past.

@ringerc

This comment has been minimized.

Member

ringerc commented Apr 18, 2014

On 04/19/2014 06:58 AM, Sehrope Sarkuni wrote:

After startup the JDBC driver checks the server version and if it's 9.0+
it sets the |extra_float_digits| and optionally the |application_name|.
Setting each of these requires a couple of round trips as each is
executed in its own |SET foo = 'bar'| statement.

If you know the remote server is 9.0+ then you can instead send both
properties in the StartupMessage itself.

This patch adds a property to instruct the driver that the server you
are connecting to is a "modern server", i.e. 9.0+. For lack of a better
name I've called the property |isModernServer|.

That won't make any sense at all in two years time.

Instead, provide a parameter that lets the user specify the minimum
version that should be supported. Something like:

assumeMinServerVersion=9.0

Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

@sehrope

This comment has been minimized.

Contributor

sehrope commented Apr 19, 2014

I just saw your message but in the meantime I had posted the idea on the JDBC mailing list and came to the same conclusion of instead having an minServerVersion property. Something else down the road could use the value as well. I'll update the patch.

On a related note, I'd prefer this being default behavior down the road (after 8.4 is EOL). It's a (minor) pain to add an extra connection property to all JDBC urls and it would be nice to get it automatically.

Add an assumeMinServerVersion connection property.
Add an assumeMinServerVersion connection property to specify the expected server_version of the remote server.
If this property is set to 9.0+ (ex: 9.0, 9.1, 9.2, 9.3, etc) then the driver will add additional parameters to the StartupMessage that would otherwise be sent afterward in run InitialQueries().
For 9.0+ database this will save a number of round trips at connection creation as the parameters are otherwise set via individual SET statements in runInitialQueries().
@sehrope

This comment has been minimized.

Contributor

sehrope commented Apr 19, 2014

I updated the patch to instead have a assumeMinServerVersion property. It now checks that it's 9.0+.

FYI, the version comparison itself is done via the String compareTo(...) and I left a note there that it needs to be updated to support two-digit major/minor versions. The rest of the driver has similar code as well (ex: see AbstractJdbc2Connection) so I figure it can be centrally fixed later.

@davecramer

This comment has been minimized.

Member

davecramer commented Apr 21, 2014

I'd like to see an update to the docs, as well as a test case for this.

@sehrope

This comment has been minimized.

Contributor

sehrope commented Apr 21, 2014

Yes I'll be adding both. I've tested it locally against a couple PG versions but I'm still trying to figure out how the travis-ci setup works for pgjdbc.

Is pgjdbc tested against multiple versions of PG or is the travis-ci just the default 9.1 DB?

@davecramer

This comment has been minimized.

Member

davecramer commented Apr 21, 2014

At the moment all Travis does is build and run the tests. I didn't have
time to figure out how to check for success. If you figure it out I'd be
grateful

Dave Cramer

On 21 April 2014 11:15, Sehrope Sarkuni notifications@github.com wrote:

Yes I'll be adding both. I've tested it locally against a couple PG
versions but I'm still trying to figure out how the travis-ci setup works
for pgjdbc.

Is pgjdbc tested against multiple versions of PG or is the travis-ci just
the default 9.1 DB?


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

davecramer added a commit that referenced this pull request Apr 25, 2014

Merge pull request #144 from sehrope/faster-startup
Speed up connection creation on 9.0+

@davecramer davecramer merged commit 5aadee9 into pgjdbc:master Apr 25, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@sehrope sehrope deleted the sehrope:faster-startup branch Apr 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment