Re: Upgrading JDBC driver from 7.3 to 8.4 affected execution plans
От | Maciek Sakrejda |
---|---|
Тема | Re: Upgrading JDBC driver from 7.3 to 8.4 affected execution plans |
Дата | |
Msg-id | AANLkTimhmDfieczBdDwhRizN2w0jtH5q9zL62E6_+kyY@mail.gmail.com обсуждение исходный текст |
Ответ на | Upgrading JDBC driver from 7.3 to 8.4 affected execution plans (Boris <boris.partensky@gmail.com>) |
Ответы |
Re: Upgrading JDBC driver from 7.3 to 8.4 affected execution plans
|
Список | pgsql-jdbc |
> 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
В списке pgsql-jdbc по дате отправления: