Re: PATCH: Batch/pipelining support for libpq
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: PATCH: Batch/pipelining support for libpq |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F641DD9@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: PATCH: Batch/pipelining support for libpq (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: PATCH: Batch/pipelining support for libpq
|
Список | pgsql-hackers |
Hello, Craig, I'm sorry to be late to review your patch. I've just been able to read the HTML doc first. Can I get the latest .patchfile for reading and running the code? Here are some comments and questions. I tried to avoid the same point as other reviewers, but there may be an overlap. (1) The example UPDATE mytable SET x = x + 1; should be UPDATE mytable SET x = x + 1 WHERE id = 42; (2) "The server usually begins executing the batch before all commands in the batch are queued and the end of batch command issent." Does this mean that the app developer cannot control or predict how many TCP transmissions a batch is sent with? For example,if I want to insert 10 rows into a table in bulk, can I send those 10 rows (and the end of batch command) efficientlyin one TCP transmission, or are they split by libpq into multiple TCP transmissions? (3) "To avoid deadlocks on large batches the client should be structured around a nonblocking I/O loop using a function likeselect, poll, epoll, WaitForMultipleObjectEx, etc." Can't we use some (new) platform-independent API instead of using poll() or WaitForMultipleObject()? e.g. some thin wrapperaround pqWait(). It seems a bit burdonsome to have to use an OS-specific API to just wait for libpq. Apart fromthat, it does not seem possible to wait for the socket in 64-bit apps on Windows, because SOCKET is 64-bit while PQsocket()returns int. [winsock2.h] /** The new type to be used in all* instances which refer to sockets.*/ typedef UINT_PTR SOCKET; Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: