Skip site navigation (1) Skip section navigation (2)

Re: Prepared Statements vs. pgbouncer

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Prepared Statements vs. pgbouncer
Date: 2007-09-29 22:55:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
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.


In response to


pgsql-jdbc by date

Next:From: Paul LindnerDate: 2007-09-30 07:07:25
Subject: Re: Prepared Statements vs. pgbouncer
Previous:From: Oliver JowettDate: 2007-09-29 22:50:10
Subject: Re: Prepared Statements vs. pgbouncer

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group