> Not sure what I can do about this behavior though other than switching
> off hash/merge joins, which we did. I looked through the source, and
> preparedThreshold is set to 5 by default in 8.4.
I'd try mucking around with prepareThreshold. Chances are, you'll get
different plans once you hit the threshold, so if you're getting a bad
plan right off the bat, I'd set the threshold to 0 (or maybe 1; I'm
not sure if 0 acts as a "never prepare" value). If you're getting a
bad plan only once you hit the threshold, jack up the threshold to
Integer.MAX_VALUE or something like that.
Based on the page you linked in the subsequent e-mail, the issue may
be different than I originally thought (it looks like the old driver
didn't use server-side prepared statements at all), but I'm almost
certain there's a better way to address this than turning off
hashjoins and mergejoins. To help debug, you can turn up debugging
logging when you kick off the server (something like pg_ctl start ...
-o "-d 2", or via postgresql.conf), and see exactly which statements
are being issued by the driver, then explain them (note that you *can*
explain an EXECUTE). Once you've got that isolated, you may be able to
get additional help on the -performance list.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
