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,
$2, $3 ) corresponds to some SQL query, but it wouldn't plan it yet. Just
like a SQL function.
When invoking EXECUTE foo( 1,2,3 ) on any given connection the statement
would get prepared and planned. Then on subsequent invocations I'd just
get the previously prepared plan.

Is this planned ?

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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(
> $1, $2, $3 ) corresponds to some SQL query, but it wouldn't plan it yet.
> Just like a SQL function.
> When invoking EXECUTE foo( 1,2,3 ) on any given connection the
> statement would get prepared and planned. Then on subsequent invocations
> I'd just get the previously prepared plan.

How would that be different from the current PREPARE/EXECUTE? Do you
mean you could PREPARE in one connection, and EXECUTE in another? If
you're using persistent connections, it wouldn't be any faster than
doing a PREPARE once in each connection.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"PFC" <lists@peufeu.com> 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 harm than good and there are no
plans to implement anything like that.

For a web application though you would expect to be executing the same queries
over and over again since you would be executing the same pages over and over
again. So just a regular prepared query ought to good for your needs.

You do not want to be reconnecting to the database for each page fetch.
Replanning queries is the least of the problems with that approach.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster