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.

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.