I am from pgsql-jdbc, so I may not be "in the thread", so please ignore
places where my misunderstanding goes out.
The main two questions, IMHO, is:
1) What is the key to plan cache. Current option is some statement key
(id). Another option would be statement text (you still need to store it
"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
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
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
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:
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
"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
[ cc'd to pgsql-jdbc which seems the group most likely to be affected
by any protocol change ]
So I've been working on a plan cache module per my earlier proposal,
and I've run up against a problem with getting exec_parse_message
to use it. The problem is that the current rather hackish handlin
