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 по дате отправления: