Thanks, this was very helpful. I will experiment with those settings.
On Mon, Oct 4, 2010 at 12:13 PM, Maciek Sakrejda <msakrejda@truviso.com> wrote:
>> 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
>