Re: postgresql recommendation memory
От | David Rees |
---|---|
Тема | Re: postgresql recommendation memory |
Дата | |
Msg-id | CAHtT9Rs0M_HN6WpFKmJC0FHdG+vycSY03hEBO3q5bTC8q8Yq9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgresql recommendation memory (Scott Marlowe <scott.marlowe@gmail.com>) |
Список | pgsql-performance |
On Wed, Nov 6, 2013 at 8:35 AM, Scott Marlowe <scott.marlowe@gmail.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
В списке pgsql-performance по дате отправления: