From: | David Brown <dave(at)spoonguard(dot)org> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | PostgreSQL Global Development Group <pgsql-patches(at)postgresql(dot)org>, Charlie Peck <charliep(at)cs(dot)earlham(dot)edu> |
Subject: | Re: Allow pooled connections to list all prepared queries |
Date: | 2004-12-26 02:08:23 |
Message-ID: | 20041226020823.GA19100@lan.spoonguard.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-12-26 03:07:55 | Re: Allow pooled connections to list all prepared queries |
Previous Message | Kris Jurka | 2004-12-26 00:05:07 | Re: Allow pooled connections to list all prepared queries |