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
[ 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
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
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 :-(
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:
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
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 need
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 unnamed
