Well, that's not completely trivial => the plan might depend upon the
concrete value of $1,$2 and $3.
When you use PREPARE, it doesn't. I could live with that.
The purpose of this would be to have a library of "persistent prepared
statements" (just like lightweight functions) for y
"PFC" <[EMAIL PROTECTED]> writes:
> Suppose a web application with persistent database connections.
> I have some queries which take longer to plan than to execute !
There have periodically been discussions about a shared plan cache but
generally the feeling is that it would do more h
Well, that's not completely trivial => the plan might depend upon the concrete
value of $1,$2 and $3.
Andreas
-- Ursprüngl. Mitteil. --
Betreff: [PERFORM] PREPARE and stuff
Von:PFC <[EMAIL PROTECTED]>
Datum: 23.06.2007 21:31
Suppose a web ap
PFC wrote:
Suppose a web application with persistent database connections.
I have some queries which take longer to plan than to execute !
I with there was a way to issue a PREPARE (like "PERSISTENT PREPARE").
Now all Postgres connections would know that prepared statement foo(
Suppose a web application with persistent database connections.
I have some queries which take longer to plan than to execute !
I with there was a way to issue a PREPARE (like "PERSISTENT PREPARE").
Now all Postgres connections would know that prepared statement foo( $1,