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 <stark@enterprisedb.com> 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
>
