>> I'm not sure if we can implement this according to the current spec
>> without losing any performance benefit of addBatch()/executeBatch() - we'd
>> have to send a Sync after every individual query.
>
> But is roundtrip needed for each sync? Can't we send all the data + as much
> syncs as needed and then collect responses. The only thing that bothers me
> is famous bug when receive and then send buffer overflows.
I was thinking about something like that, too. It sort of abuses the
intent (or at least half the intent) of the Sync message, but maybe
that's acceptable.
> How about addBatch("commit") after each addBatch("update")? This should work
> in very similar way to sending Sync after each query.
This could potentially be used under the covers as a solution (instead
of just a workaround), no? I.e., when a user does an addBatch("some
SQL"), we could prepend that with a BEGIN, and follow it with a COMMIT
under the covers. If BEGIN / COMMIT have to follow the extended query
protocol, that's going to add some overhead, since each one will need
a Parse, Bind, Describe, Execute, and Close message. Conceptually,
this is similar to the async-Sync you suggested above. Unfortunately,
this is probably even uglier.
As Oliver mentioned, though, this is all pointless if the network
latency is negligible compared to the transaction overhead of the
individual statements, which is typically likely.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
