Re: jdbc spec violation for autocommit=true & addbatch/executeBatch
От | Maciek Sakrejda |
---|---|
Тема | Re: jdbc spec violation for autocommit=true & addbatch/executeBatch |
Дата | |
Msg-id | AANLkTikXzgFYjgFQLQo+CQk4irkvFx8Rxo4AVQAL47R=@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: jdbc spec violation for autocommit=true & addbatch/executeBatch (Vitalii Tymchyshyn <tivv00@gmail.com>) |
Список | pgsql-jdbc |
>> 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
В списке pgsql-jdbc по дате отправления: