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  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: bogus: logical replication rows/cols combinations
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: bogus: logical replication rows/cols combinations