Re: binary patch problems
От | Tom Lane |
---|---|
Тема | Re: binary patch problems |
Дата | |
Msg-id | 16752.1316443632@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: binary patch problems (Mikko Tiihonen <mikko.tiihonen@nitorcreations.com>) |
Ответы |
Re: binary patch problems
|
Список | pgsql-jdbc |
Mikko Tiihonen <mikko.tiihonen@nitorcreations.com> writes: > On 09/19/2011 01:11 PM, Bodor Andras wrote: >> Why don't you set prepareThreshold to 0 for your test cases? >> In this case parameter passing starts immediately for the >> prepared statement, and ForceBinaryTransfers can be dropped. > AbstractJdbc2Statement: > public boolean isUseServerPrepare() { > return (preparedQuery != null && m_prepareThreshold != 0 && m_useCount + 1 >= m_prepareThreshold); > } > If I read the above correctly then prepareThreshold of 0 disables prepared statements. But "1" would do what you want, no? FWIW, I'm hoping that this entire business of delaying the server-side prepare will be obsolete as of 9.2. There is already code committed in HEAD that allows "prepared" statements to be re-planned for each new set of parameter values, with a somewhat-informed choice of whether and when to switch over to the traditional generic-plan approach. It needs tweaking for performance still, no doubt, but there is not going to be a reason for the driver to do this anymore. Obviously that's not much use for solving your immediate problem, but it might lead you to conclude that putting a large amount of effort into improving this mechanism would be a dead end. regards, tom lane
В списке pgsql-jdbc по дате отправления: