Re: Prepared Statements vs. pgbouncer - Mailing list pgsql-jdbc

From Josh Berkus
Subject Re: Prepared Statements vs. pgbouncer
Date
Msg-id 46FE3B1A.7020603@agliodbs.com
Whole thread Raw
In response to Re: Prepared Statements vs. pgbouncer  (Paul Lindner <lindner@inuus.com>)
Responses Re: Prepared Statements vs. pgbouncer
List pgsql-jdbc
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


pgsql-jdbc by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Prepared Statements vs. pgbouncer
Next
From: Paul Lindner
Date:
Subject: Re: Prepared Statements vs. pgbouncer