On Tue, 13 Apr 2004, James Robinson wrote:
>
> 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?
>
I've reviewed it and it basically looks good, but I came across a general
issue with server prepared statements not specific to Oliver's patch.
Essentially when doing "int count = prepStmt.executeUpdate()" the count is
never set for server prepared statements. I've raised this issue on
hackers: http://archives.postgresql.org/pgsql-hackers/2004-03/msg00923.php
Basically I want to run the whole regression tests with everything using
server prepared statements cleanly. Sure the patch doesn't affect the
long standing behavior, but it makes in much more accessible and I'd
expect a number of bug reports. There were a number of other failures as
well, but I don't recall what they are at the moment.
Kris Jurka