Re: Prepared Statements vs. pgbouncer

Paul Lindner wrote:
> I appear to have stirred the pot a little too vigorously.. Let's take
> a deep breath and take a step back..
>
> First off, I really appreciate the hard work that's gone into the
> design and implementation of Postgres and the JDBC driver. I realize
> that what I'm trying to do falls outside of the norms -- hopefully the
> following background information will help everyone understand what
> I'm trying to achieve:

Actually, I wouldn't say it "goes outside the norm". While the majority
of JDBC users will use J2EE connection pooling rather than pgBouncer, as
more and more users want to scale up to 1 million connections (yes,
really, we even put in a bid for a customer with this spec) J2EE pooling
won't be enough ... you'll need both.

So we're going to have to troubleshoot this sooner or later.

Actually, in that kind of an application, I don't see the theoretical
issue with S_1 being reused by different client connections. In an
ideal world, this would give us de-facto shared prepared plans. Or am I
misunderstanding the issue?

Also, should I understand that there now is no way in pgsql-jdbc to turn
prepared plans off, even if you want to?

--Jsoh