-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Kings-Lynne wrote:
> Say we have a query that takes 350ms to get threads in a forum, and half
> of that is planning time. Any particular PHP process does not know if a
> previous process has already prepared that query or not. So I ha
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 add
On Mon, Dec 27, 2004 at 01:03:08PM -0500, Kris Jurka wrote:
has not prepared. So I don't see why, simply because it's in a pool, that
it forgets what's been prepared.
The connection (the open socket to Postgres) doesn't forget anything. If
you have multiple machines sharing a connection pool, t
Hi Tom:
On Fri, Dec 24, 2004 at 11:00:57AM -0500, Tom Lane wrote:
* Extended PostgreSQL's SQL grammar to capture the original SQL query
string for PREPARE statements.
This seems much the ugliest and most invasive part of the patch. I'd
suggest doing something similar to what pg_proc.c is doin
On Sat, 25 Dec 2004, David Brown wrote:
> 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 pool
The usefulness of this seems pretty dubious. You aren't going to have a
bunch of random bits of code sharing a connection; it's going to be a
single application that probably knows perfectly well exactly which
queries it needs prepared. So I don't think the stats will pay for
themselves.
Not true
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
On Wed, 22 Dec 2004, David Brown wrote:
> This would allow an application inheriting a pooled connection to know
> the queries prepared in the current session.
>
I don't see this as all that helpful for a client interface that does the
preparation itself. Possibly it could be used for
David Brown <[EMAIL PROTECTED]> writes:
> Attached is a loadable module (and a small backend patch) that allows a
> client to list the available query plans (created with PREPARE, or with a
> 'parse' protocol message) on a particular connection.
> * Extended PostgreSQL's SQL grammar to capture
Hi:
Attached is a loadable module (and a small backend patch) that allows a
client to list the available query plans (created with PREPARE, or with a
'parse' protocol message) on a particular connection.
This work was done in response to an item in the TODO:
* Allow pooled connections to list a
10 matches
Mail list logo
