Re: Allow pooled connections to list all prepared queries

Hi Kris:

On Sat, Dec 25, 2004 at 07:05:07PM -0500, Kris Jurka wrote:
>I don't see this as all that helpful for a client interface that does the
>preparation itself.  Possibly it could be used for libpq, but you
>mentioned DBI which should already know what it has or has not prepared.
>The idea of adding a network round trip to detect a prepared statement
>seems like a performance loss, not a gain.  If this is just to avoid
>repreparing the same statement then perhaps something like PREPARE OR
>REPLACE would be more useful.

You're right, in the case of standalone Perl or Apache::DBI. However, if
DBD::Pg happens to grab an already-open connection that doesn't have a
one-to-one correspondence with a $dbh (e.g. from a Postgres connection pool,
or from an external pooling server like DBBalancer[1]), the state of the
connection (with respect to past PREPAREs) isn't known.

In the case of an external-to-Perl connection pool, We'd make one round trip
to the server to fill in DBD::Pg's list of prepared statements, at
DBD::Pg::db::connect() - not at every prepare (which, as you said, would be
a net loss).

(DBD:::Pg, in fact, ships with server-side prepares totally turned off. I
have some code that fixes that for the SELECT and DELETE cases, but it, like
the rest of this stuff, isn't really release-quality yet.)

[1] http://dbbalancer.sourceforge.net

Thanks,

- Dave