Re: [PERFORM] PREPARE and stuff

2007-06-23 Thread PFC
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

Re: [PERFORM] PREPARE and stuff

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

Re: [PERFORM] PREPARE and stuff

2007-06-23 Thread Andreas Kostyrka
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

Re: [PERFORM] PREPARE and stuff

2007-06-23 Thread Heikki Linnakangas
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(

[PERFORM] PREPARE and stuff

2007-06-23 Thread PFC
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,