Re: Under what circumstances does PreparedStatement use stored
От | James Robinson |
---|---|
Тема | Re: Under what circumstances does PreparedStatement use stored |
Дата | |
Msg-id | 0B7BADD2-8DA9-11D8-8D1B-000A9566A412@socialserve.com обсуждение исходный текст |
Ответ на | Re: Under what circumstances does PreparedStatement use stored (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Under what circumstances does PreparedStatement use stored
|
Список | pgsql-jdbc |
On Apr 13, 2004, at 6:36 PM, Oliver Jowett wrote: > So (with my original patch) you'd still get the benefit of > PREPARE/EXECUTE after the first N items are updated, but it's not > going to be as fast as you expect regardless.. > > But even with a smarter implementation it seems simple enough: count > each addBatch() towards the threshold and check the threshold on > executeBatch(). It sounds to me like Oliver's original patch would solve most all 'normal' cases reasonably well, including the case when people would want all PreparedStatements to be server-side prepared via setting the threshold to 1. It would not solve the 'fight-the-middleware cross-PreparedStatement pooling' scenario I face, but it sounds like a little-to-loose patch -- backwards compatibility is maintained, and you can get server-preparation without downcasting if so desired, either always or past a static barrier. Is it a candidate for commitment? ---- James Robinson Socialserve.com
В списке pgsql-jdbc по дате отправления: