From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tim Fors <tim4stheenchanter@gmail.com>
cc: pgsql-performance@lists.postgresql.org
Subject: Re: Client-server communication for FETCH
In-reply-to: 
 <CAOjiQ0C7NEV9ZBFxbM6KgXnzquaUY3MrN1x8vz_tv7uXac0UwQ@mail.gmail.com>
References: 
 <CAOjiQ0C7NEV9ZBFxbM6KgXnzquaUY3MrN1x8vz_tv7uXac0UwQ@mail.gmail.com>
Comments: In-reply-to Tim Fors <tim4stheenchanter@gmail.com>
	message dated "Wed, 03 Dec 2025 13:02:40 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <689685.1764787308.1@sss.pgh.pa.us>
Date: Wed, 03 Dec 2025 13:41:48 -0500
Message-ID: <689686.1764787308@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/689686.1764787308%40sss.pgh.pa.us>
Precedence: bulk

Tim Fors <tim4stheenchanter@gmail.com> writes:
> I have a simple C program using libpq V18 to FETCH one row at a time (see
> below). Does the server send multiple rows to the client where they are
> cached for satisfying the FETCH statements, or does it just send one row at
> a time since that's all that each FETCH statement is asking for?

It's sending one row at a time.  You could improve that by asking
for more than one row ("FETCH n" not just "FETCH"), but you'd have
to iterate over the rows returned by each command.

Another alternative is to forget about using a cursor, tell the
server to just execute the query, but use libpq's "chunked results"
mode to process rows before all of the query result has arrived.
See

https://www.postgresql.org/docs/current/libpq-single-row-mode.html

> I have done extensive searching to try and find the definitive answer to
> this. The searches indicate that libpq supports the concept of a
> client-side cursor, where it has a cache of rows sent by the server and
> uses that cache to perform each FETCH, but I'd like to be able to verify
> whether this is true or not.

Don't know where you read that, but it's not true of libpq.  There
might be other Postgres client libraries that can do that.

			regards, tom lane