| 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: | Whole Thread | Raw Message | 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 |