Skip site navigation (1) Skip section navigation (2)

Re: jdbc driver performance TODO

From: Kris Jurka <books(at)ejurka(dot)com>
To: "Strong, David" <david(dot)strong(at)unisys(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: jdbc driver performance TODO
Date: 2006-10-31 19:32:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

On Tue, 31 Oct 2006, Strong, David wrote:

> Here's an observation about the JDBC driver, but I'm not sure if it's
> practical to implement. After preparing a statement, the driver still
> sends out a describe message either via the sendDescribeStatement () or
> (most likely) the sendDescribePortal () method calls in
> org.postgresql.core.v3.QueryExecutorImpl. However, as the statement has
> been prepared, it's unlikely to change and so the results of the
> sendDescribeXXX () could be requested once and then cached with the
> prepared statement.

I'm not sure how much benefit this will actually produce, but I agree 
there is duplication of work here.

> Of course, if any tables referenced by the query where changed, the
> prepared statement would be caching the original structure. Although,
> I'm not sure how much of a problem this would be as changing a table's
> data types etc. might cause code to break anyway.

Right now it's not a big deal for the driver because plans don't change, 
but for 8.3 there are plans to do prepared query invalidation when 
underlying tables change.  At that point we'd need to detect and refetch 
metadata.  I'm not sure how a client would detect this change.

> I don't see a direct way to turn off the metadata, perhaps I'm missing
> something?

Passing the QueryExecutor.QUERY_NO_METADATA flag to the QueryExecutor will 
prevent the describe message from being sent.

Kris Jurka

In response to


pgsql-jdbc by date

Next:From: Tom LaneDate: 2006-10-31 21:20:34
Subject: Re: jdbc driver performance TODO
Previous:From: Kris JurkaDate: 2006-10-31 19:14:54
Subject: Re: confused about transactions and connection pools

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group