From: | James Robinson <jlrobins(at)socialserve(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org, Michael Nonemacher <Michael_Nonemacher(at)messageone(dot)com> |
Subject: | Re: Under what circumstances does PreparedStatement use stored |
Date: | 2004-04-14 00:16:58 |
Message-ID: | 0B7BADD2-8DA9-11D8-8D1B-000A9566A412@socialserve.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2004-04-14 00:34:12 | Re: Under what circumstances does PreparedStatement use stored |
Previous Message | Oliver Jowett | 2004-04-13 23:43:41 | patch: fix TimeTest in timezones ahead of GMT |