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: Pine.BSO.4.63.0610311428220.12111@leary2.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-jdbc by date

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