"Tom Lane" <[EMAIL PROTECTED]> writes:

> B. Don't store the unnamed statement in the plan cache.  To make sure
> it's not used anymore when the plan might be stale, forcibly discard
> the unnamed statement after execution.  This would get rid of a lot
> of overhead but would mean a significant change in the protocol-level
> behavior.  It's hard to guess how many clients might be broken by it
> --- conceivably not any, but that seems too optimistic :-(

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.

Or stash the query string and replan it (possibly in the query cache this
time) if someone executes it a second time?

Can't say I like either of those options much, just trying to brainstorm.

  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to