Re: [HACKERS] Plan invalidation vs. unnamed prepared statements

2007-03-06 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Tue, 2007-03-06 at 12:22 -0500, Tom Lane wrote: >> A. Just accept the extra overhead, thereby preserving the current >> behavior of unnamed statements, and gaining the benefit that plan >> invalidation will work correctly in the few cases where an unna

Re: [HACKERS] Plan invalidation vs. unnamed prepared statements

2007-03-06 Thread Simon Riggs
On Tue, 2007-03-06 at 12:22 -0500, Tom Lane wrote: > A. Just accept the extra overhead, thereby preserving the current > behavior of unnamed statements, and gaining the benefit that plan > invalidation will work correctly in the few cases where an unnamed > statement's plan lasts long enough to ne

Re: [HACKERS] Plan invalidation vs. unnamed prepared statements

2007-03-06 Thread andyk
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

Re: [HACKERS] Plan invalidation vs. unnamed prepared statements

2007-03-06 Thread Tom Lane
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

Re: [HACKERS] Plan invalidation vs. unnamed prepared statements

2007-03-06 Thread Gregory Stark
"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 ch