Re: Libpq single-row mode slowness
От | Tom Lane |
---|---|
Тема | Re: Libpq single-row mode slowness |
Дата | |
Msg-id | 1708086.1651439546@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Libpq single-row mode slowness (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Libpq single-row mode slowness
|
Список | pgsql-hackers |
Daniele Varrazzo <daniele.varrazzo@gmail.com> writes: > The operations we perform, for every row, are PQconsumeInput, > PQisBusy, PQgetResult. Every PQconsumeInput results in a recvfrom() > syscall, of which the first one returns the whole recordset, the > following ones return EAGAIN. There are two extra cycles: one to get > the TUPLES_OK result, one to get the end-of-stream NULL. It seems the > documented usage pattern, but I'm not sure if I'm not misreading it, > especially in the light of this libpq grumble [1]. The usual expectation is that you call PQconsumeInput to get rid of a read-ready condition on the socket. If you don't have a poll() or select() or the like in the loop, you might be wasting a lot of pointless recvfrom calls. You definitely don't need to call PQconsumeInput if PQisBusy is already saying that a result is available, and in single-row mode it's likely that several results can be consumed per recvfrom call. regards, tom lane
В списке pgsql-hackers по дате отправления: