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
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 |