Re: Prepared Statements vs. pgbouncer

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Prepared Statements vs. pgbouncer
Дата
Msg-id 46FE3B1A.7020603@agliodbs.com
обсуждение исходный текст
Ответ на Re: Prepared Statements vs. pgbouncer  (Paul Lindner <lindner@inuus.com>)
Ответы Re: Prepared Statements vs. pgbouncer  (Oliver Jowett <oliver@opencloud.com>)
Список 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 по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Prepared Statements vs. pgbouncer
Следующее
От: Paul Lindner
Дата:
Сообщение: Re: Prepared Statements vs. pgbouncer