Re: Prepared Statements vs. pgbouncer

Paul Lindner wrote:

>   2) Before preparing a statement with a hashed name, send a close
>      statement to insure that we don't get an error inside of a
>      transaction.

But that defeats the purpose of using a named statement in the first
place -- and any potential benefit you'd get by sharing statements
between clients -- if you're going to throw it away before reusing it
every time!

> This is just as performant as the current driver which will happily
> re-prepare the same SQL many times.

No. The current driver will switch to a named statement that is prepared
*once* when it thinks there is a benefit to doing so (tunable via
prepareThreshold). Your change would mean that it would always
re-prepare statements. Unless you're talking about a statement cache so
that applications don't have to hold onto a particular PreparedStatement
object to get the benefit of reuse, which arguably is the responsibility
of the appserver (see the list archives for recent discussion of this).

> I do hope that you'll find any work done
> useful for general consumption.

Unfortunately, I still don't really see any these solutions to your
particular problem as something that'd be useful in the general driver.
I think your efforts would be better spent in teaching pgbouncer to deal
with named statements properly..

-O