Re: Libpq single-row mode slowness - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Libpq single-row mode slowness
Date
Msg-id 1708086.1651439546@sss.pgh.pa.us
Whole thread Raw
In response to Libpq single-row mode slowness  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Responses Re: Libpq single-row mode slowness  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: bogus: logical replication rows/cols combinations
Next
From: Tomas Vondra
Date:
Subject: Re: bogus: logical replication rows/cols combinations