On Tue, 2006-10-31 at 14:32 -0500, Kris Jurka wrote:
>
> 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.
So we can optimise it, but only for 8.2 and below until we work out the
next steps.
> > 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.
Plus we have the difference between changed plans that change metadata
and changed plans that do not change metadata. The latter might well be
considered to be more common, though both are fairly rare in the context
of the prepared statement.
So we probably can do something with this, but plans haven't really been
thought through yet. So, this is a good reminder of something to include
in the mix when designs start to be proposed.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com