Re: jdbc driver performance TODO

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: "Strong, David" <david(dot)strong(at)unisys(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: jdbc driver performance TODO
Date: 2006-10-31 21:20:34
Message-ID: 8940.1162329634@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Kris Jurka <books(at)ejurka(dot)com> writes:
> 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.

We haven't really talked about the semantics of this stuff, but I'm
inclined to think that a prepared statement ought to go into some kind
of "broken" status where it couldn't be invoked, if a change occurs that
would force a change in the output column set. Otherwise you could have
situations where a client does Describe Statement followed (almost)
immediately by Execute and gets inconsistent results. I think we really
want the auto-replan facility to handle things like addition of a new
index or availability of new ANALYZE stats --- having it automatically
propagate things like an ALTER COLUMN TYPE seems a good bit more
questionable.

regards, tom lane

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message ludovic orban 2006-11-01 10:02:56 Re: XA end then join fix for WebLogic
Previous Message Kris Jurka 2006-10-31 19:32:05 Re: jdbc driver performance TODO