From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
cc: "Stijn Sanders" <stijnsanders@gmail.com>,
        pgsql-general@lists.postgresql.org
Subject: Re: Will PQsetSingleRowMode get me results faster?
In-reply-to: <140214eb-a8ce-4285-afdd-7770c5a9d274@manitou-mail.org>
References: <140214eb-a8ce-4285-afdd-7770c5a9d274@manitou-mail.org>
Comments: In-reply-to "Daniel Verite" <daniel@manitou-mail.org>
	message dated "Mon, 06 Jan 2025 20:25:26 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1335669.1736193981.1@sss.pgh.pa.us>
Date: Mon, 06 Jan 2025 15:06:21 -0500
Message-ID: <1335670.1736193981@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1335670.1736193981%40sss.pgh.pa.us>
Precedence: bulk

"Daniel Verite" <daniel@manitou-mail.org> writes:
> 	Stijn Sanders wrote:
>> From what I notice using LibPQ, it appears a query needs to complete
>> before resulting data is being transferred to the client. Please
>> correct me if I'm wrong.

> No, the query does not need to complete. If you run something like
> "select * from bigtable" in single-row or chunked mode, you should
> see that the first results are typically available immediately to the
> application, while the query is far from finished.
> But it depends on the query plan. A lot of queries cannot produce any
> result until the final stage of their execution. For these, you can't
> expect any difference in how fast the first results are available
> client-side.

Right.  But there's yet another moving part here: when creating
a plan for a cursor query, the planner will give some preference
(not infinite preference, but some) to plans that are expected
to produce their first result row sooner.  For example it might
pick an indexscan plan on a suitably-ordered index over a
seqscan-and-sort plan, even if the indexscan is estimated to take
more time to run to completion.

So in principle, you might get best results by defining your query
with DECLARE CURSOR and then using PQsetSingleRowMode on the FETCH.
But it'd really depend on the particular query whether this gives
any benefit.

			regards, tom lane