Re: Why does the prepareThreshold=0 (to cover pgbouncer transaction mode) disables protocol binary transfers ? (w/ PoC patch and measurements)

>>
>> > Where I think JDBC (and maybe pgbouncer) is going wrong with this, is
>> > they don't make (allow for) proper use of the "unnamed prepared
>> > statement" which: "...lasts only until the next Parse statement
>> > specifying the unnamed statement as destination is issued." [2] The
>> > code does have oneShot in the parse/bind/execute path so it is
>> > recognized...at least in JDBC.
>>
>
The driver does use the unnamed statement for pretty much everything until
we see the same statement being used prepareThreshold times. Then we switch
to a named statement.

>> Session configuration. If you are using a pooler mode that simply
> doesn't play nice with named prepared statements you must configure JDBC to
> not use them (ever) and use only the unnamed prepared statement for
> parse/bind/execute. The interleaving you want to do is simply not possible
> (or, rather, you will not get the benefit of actually having the prepared
> statement saved in a cache for re-use, it will be re-parsed every time).
>
> This seems better than nothing given lots of uses of prepared statements
> are simply to get access to the extended query
> protocol's parse/bind/execute. It is quite possible an even better
> solution exists if pgJDBC and pgbouncer cooperate and design and implement
> something to overcome this complaint. I'm not going there myself (not that
> I'm implementing this suggestion) as this solution seems simpler and
> sufficiently effective for the majority of use cases. It also likely
> doesn't impose any kind of constraints (especially as this is basically
> implementation details + configuration, not code-level API changes) on a
> more nuanced solution.
>
> There are a number of other session settings that we can't really track
either.

Dave

>