Re: Prepared Statements vs. pgbouncer
От | hubert depesz lubaczewski |
---|---|
Тема | Re: Prepared Statements vs. pgbouncer |
Дата | |
Msg-id | 20071002123838.GA1462@depesz.com обсуждение исходный текст |
Ответ на | Re: Prepared Statements vs. pgbouncer (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Prepared Statements vs. pgbouncer
|
Список | pgsql-jdbc |
On Mon, Oct 01, 2007 at 02:44:10PM -0400, Tom Lane wrote: > Dave Cramer <pg@fastcrypt.com> writes: > > Josh Berkus wrote: > >> So where is it going to be easier to fix this ... pgBouncer, or pg-JDBC? > > pgBouncer is broken so I'd fix it. > It's an enormous mistake to imagine that prepared statements are the > only issue. What about GUC settings and temp tables, to mention a > couple other bits of per-session state? i think that calling it broken is "a bit" far fetched. i dont know how familiar you are with pgbouncer, but the mode in which paul ran pgbouncer is *purposedly* not working correctly with prepared statement.s basically - ppgbouncer supports 3 modes: - session pooling - transaction pooling - statement pooling. description of all of them is clear in manual: ------------------------------ Session pooling:: Most polite method. When client connects, a server connection will be assigned to it for the whole duration it stays connected. When client disconnects, the server connection will be put back into pool. Transaction pooling:: Server connection is assigned to client only during a transaction. When PgBouncer notices that transaction is over, the server will be put back into pool. Statement pooling:: Most aggressive method. The server connection will be put back into pool immidiately after a query completes. Multi-statement transactions are disallowed in this mode as they would break. ------------------------------ so, pgbouncer is not broken. if you want to keep your connection between transactions (which is perfectly sensible) - use session pooling. both transaction pooling and statement pooling are modes which trade some performance for missing features. i wouldn't suggest anyone using statement pooling, but if i would use it, then what right do i have to complain about bad transactions?! best regards, depesz -- quicksil1er: "postgres is excellent, but like any DB it requires a highly paid DBA. here's my CV!" :) http://www.depesz.com/ - blog dla ciebie (i moje CV)
В списке pgsql-jdbc по дате отправления: