Paul Lindner <lindner@inuus.com> writes: > It seems that the driver should immediately deallocate the server-side > prepared statements it creates for cursors when it finishs fetching > data for that cursor. What exactly is the argument here? That no client should use anything more than the fraction of the FE/BE protocol that pgbouncer currently supports? Pardon me for not buying into it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Oliver Jowett <oliver@opencloud.com> writes: > The driver uses server-side statements for frequently-used internal > utility commands such as BEGIN too, and the lifetime of those statements > is essentially "the whole connection", not a particular transaction. I'm kinda hijacking the thread here, because this question is unrelated to pgbouncer's behavior, but: have you ever done any performance measurement to prove that preparing BEGIN/COMMIT/ROLLBACK is a good idea? AFAICS there is only trivial parsing work to be saved, and no planning work, and yet the overhead of storing and referencing a prepared statement remains. My gut feeling is that this is at best a wash and could easily be a loss, particularly as of 8.3 which will have more overhead to maintain prepared statements. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Oliver Jowett <oliver@opencloud.com> writes: > Tom Lane wrote: >> I'm kinda hijacking the thread here, because this question is unrelated >> to pgbouncer's behavior, but: have you ever done any performance >> measurement to prove that preparing BEGIN/COMMIT/ROLLBACK is a good idea? > No benchmarks. There would be essentially no difference in the driver > code either way (literally, you'd have to add code to avoid preparing > the statement) so unless named statements are much more expensive than > unnamed ones it's probably not worth worrying about. I don't have a reason to think it's a big loss --- I was just worried that you were going out of your way to make this happen, when it's probably not a win either. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

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? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend