Re: Prepared Statements vs. pgbouncer
От | Paul Lindner |
---|---|
Тема | Re: Prepared Statements vs. pgbouncer |
Дата | |
Msg-id | 20071001210922.GQ3140@inuus.com обсуждение исходный текст |
Ответ на | Re: Prepared Statements vs. pgbouncer (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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? What if you're in a homogenous environment and can control those variables? Or for another example, what if you want to create a pool of read-only replicas and don't care which server gets the request. What about failover situations? With stateless clients and the correct pooling one could seamlessly send requests to a durable Connection, avoiding a large amount of retry logic in the individual code. Perl's adage "Make easy things easy and hard things possible" is apropos here.. ---------------------------------------------------------------------- In fact, here's a crazy idea: static pre-defined session state tied to roles: ALTER ROLE appserver_v1 PREPARE foo() AS ....; ALTER ROLE appserver_v1 PREPARE xyz() AS ....; ALTER ROLE appserver_v1 SET SESSION stateless=true; Of course this doesn't help for dynamically prepared statements, which has been my problem all along... -- Paul Lindner ||||| | | | | | | | | | lindner@inuus.com
Вложения
В списке pgsql-jdbc по дате отправления: