Re: Prepared Statements vs. pgbouncer - Mailing list pgsql-jdbc

From Marko Kreen
Subject Re: Prepared Statements vs. pgbouncer
Date
Msg-id e51f66da0710021305s39616429ke3a1f783ab01b481@mail.gmail.com
Whole thread Raw
In response to Re: Prepared Statements vs. pgbouncer  (hubert depesz lubaczewski <depesz@depesz.com>)
Responses Re: Prepared Statements vs. pgbouncer  (Josh Berkus <josh@agliodbs.com>)
List pgsql-jdbc
On 10/2/07, hubert depesz lubaczewski <depesz@depesz.com> wrote:
> 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.

Thanks, I think so too.  Considering all the other things that
are broken by transaction pooling, "it would be cute to have it"
is the best I can think of.

I did a quick feature matrix of things broken by pooler in general:

 https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer

Seems like the protocol-level plans is only one of them that
_could_ be worked around in pooler.  Rest will stay broken.

Coincidentally, the prepared plans happens to be the pet-feature
of JDBC, as I understand...


So, personally I don't have time to work on the feature, but
I have thought a draft design that could somewhat work in the
context of pgbouncer.  If anyone is interested to work on that,
contact me.

--
marko

pgsql-jdbc by date:

Previous
From: Kris Jurka
Date:
Subject: Re: statement caching link on jdbc page
Next
From: Josh Berkus
Date:
Subject: Re: Prepared Statements vs. pgbouncer