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

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 (view raw or flat)
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

pgsql-jdbc by date

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

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