| From: | David Rees <drees76(at)gmail(dot)com> |
|---|---|
| To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
| Cc: | Евгений Селявка <evg(dot)selyavka(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: postgresql recommendation memory |
| Date: | 2013-11-07 08:51:15 |
| Message-ID: | CAHtT9Rs0M_HN6WpFKmJC0FHdG+vycSY03hEBO3q5bTC8q8Yq9w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Nov 6, 2013 at 8:35 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> That's a mostly religious argument. I.e. you're going on feeling here
> that pooling in jdbc alone is better than either jdbc/pgbouncer or
> plain pgbouncer alone. My experience is that jdbc pooling is not in
> the same category as pgbouncer for configuration and performance.
> Either way, get that connection count down to something reasonable.
>
> Basically pgbouncer is veyr lightweight and can take thousands of
> incoming connections and balance them into a few dozen connections to
> the database.
I've had a look at the pgbouncer docs, and it appears that there are 3
modes: session, transaction and statement.
Session pooling appears to be the most conservative, but unless I am
missing something, I don't see how it will reduce the number of actual
database connections when used in between a JDBC connection pool?
If using Transaction pooling, it appears that you need to disable
prepared statements in JDBC - any the FAQ stays you need to apply a
patch to the JDBC driver to get it (admittedly, that FAQ appears that
it might be out of date given the JDBC version it references).
-Dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Евгений Селявка | 2013-11-07 09:33:52 | Re: postgresql recommendation memory |
| Previous Message | Merlin Moncure | 2013-11-06 23:18:18 | Re: postgresql recommendation memory |