I think C is how the JDBC driver is written. We name the statements
if they have been used more than prepareThreshold times.
So we have a mechanism by which to allow statements to be cached, or
not.
Dave
On 6-Mar-07, at 1:14 PM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Can we forcibly discard it if *any* messages are received that might
invalidate a plan? So basically it would work fine unless anyone
in the system
does any DDL at all? I guess that has the downside of introducing
random
unpredictable failures.
Ugh :-(
Or stash the query string and replan it (possibly in the query
cache this
time) if someone executes it a second time?
I think that's either my plan A or C.
The main problem with uncontrolled replanning is that there's no
way to
detect a change in the query properties. For example suppose the
query
is "SELECT * FROM foo" and we've already told the client (via Describe
Statement) that that returns two integer columns. If an inval now
arrives because of "ALTER TABLE foo ADD COLUMN" (or perhaps worse,
ALTER
COLUMN TYPE), we've got a problem. If we just blindly replan then
we'll
return tuples that do not match the previously given row description,
which will certainly break most clients.
The plan caching module has enough infrastructure to detect and
complain
about these sorts of situations, and it also knows how to manage lock
acquisition so that once we've decided a plan is still good, the
tables
won't change underneath us while we use the plan. I don't see any way
to make comparable guarantees without the overhead that goes with the
cache manager.
regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
