Re: executeBatch() issue with new driver?

Поиск
Список
Период
Сортировка
Искать
От
Oliver Jowett
Тема
Re: executeBatch() issue with new driver?
Дата
Msg-id
4187F43B.2070505@opencloud.com
Ответ на
Список
Дерево обсуждения
executeBatch() issue with new driver? Alan Stange <stange@rentec.com>
Re: executeBatch() issue with new driver? Dave Cramer <pg@fastcrypt.com>
Re: executeBatch() issue with new driver? Alan Stange <stange@rentec.com>
Re: executeBatch() issue with new driver? Dave Cramer <pg@fastcrypt.com>
Re: executeBatch() issue with new driver? Alan Stange <stange@rentec.com>
Re: executeBatch() issue with new driver? Kris Jurka <books@ejurka.com>
Alan Stange wrote:

>> Especially since you are already using addBatch, there doesn't seem to 
>> be much point in jamming two commands into one batch.
>>
> Network latency.   We were able to greatly increase performance this way 
> by reducing the number of round trips.

If you give the development driver multiple queries via *multiple* 
addBatch() calls, it will avoid the extra round trips.

i.e. if you do:

   stmt.addBatch("CREATE TABLE ...");
   stmt.addBatch("INSERT ...");
   stmt.executeBatch();

then the driver will only do one round trip.

There is a limit of somewhere around 100 queries per round-trip (from 
memory) due to some issues with avoiding network deadlocks, but in 
practice that won't have much effect on performance.

AFAIK this is exactly what addBatch/executeBatch is there for. It's just 
that the older driver was not particularly smart about handling this 
case, so you had to shoehorn multiple statements into one query to get 
the same effect.

Both driver versions should handle multiple queries per query string if 
you use the normal query execution interface rather than the batch 
interface. The older driver doesn't handle multiple resultsets per 
query, but multiple updates (or other queries that do not return 
results) should be fine.

-O
В списке pgsql-jdbc по дате отправления
От: Alan Stange
Дата:
От: Aaron Mulder
Дата:
FAQ