Re: Prepared Statements vs. pgbouncer

Josh Berkus wrote:

> Actually, in that kind of an application, I don't see the theoretical
> issue with S_1 being reused by different client connections.  In an
> ideal world, this would give us de-facto shared prepared plans.  Or am I
> misunderstanding the issue?

S_1 from client 1 might be a completely different query to S_1 from
client 2. The JDBC driver just numbers statements sequentially as they
are used.

> Also, should I understand that there now is no way in pgsql-jdbc to turn
> prepared plans off, even if you want to?

Right, and there never has been something like that since the V3 code
was first added back in the (7.4? 8.0?) driver. Named statements are
part of the V3 protocol, the driver expects the full protocol to be
available. As I said if you wanted you could do driver modifications to
tell the V3 protocol layer never to use named statements if you really
wanted to, but if you're talking to something that implements the full
V3 protocol (like, um, a postgresql backend..) there's no need. There
are already knobs which let you tune whether user-generated queries use
named statements or not, mostly because there are potential performance
differences (unnamed statements can benefit from knowing the actual
parameter values). For internal driver-generated queries that has not
been an issue in the past so there's no tuning knob for them.

-O