public inbox for [email protected]
help / color / mirror / Atom feedRe: Will PQsetSingleRowMode get me results faster?
2+ messages / 2 participants
[nested] [flat]
* Re: Will PQsetSingleRowMode get me results faster?
@ 2025-01-06 20:06 Tom Lane <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2025-01-06 20:06 UTC (permalink / raw)
To: Daniel Verite <[email protected]>; +Cc: Stijn Sanders <[email protected]>; [email protected]
"Daniel Verite" <[email protected]> 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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Will PQsetSingleRowMode get me results faster?
@ 2025-04-04 11:41 Stijn Sanders <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Stijn Sanders @ 2025-04-04 11:41 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Daniel Verite <[email protected]>; [email protected]
On Mon, Jan 6, 2025 at 9:06 PM Tom Lane <[email protected]> wrote:
> 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.
That's a really nice suggestion, and it took me some time to set up a
suitable test environment to see if it would work, but using separate
PQsendquery/PQexec calls for:
start transaction read only
declare cr1 no scroll cursor for select (and the rest of my query)
fetch next in cr1
it seems like the fetch instruction still takes about as much time as
the full 'normal' select would, I tried a few different queries, but
I'm still suspecting PostgreSQL's internals is waiting for the data to
all 'be ready' before it can send any data over, even if these
PQgetResult's for each fetch will have a PQntuples of 1.
(I even tried with "fetch 8", and PQntuples neatly serves 8 at a time,
but still after about the same time PQsendquery(,'select... would
take)
Or could there still be something that I'm doing that prevents 'firehosing'?
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-04-04 11:41 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-01-06 20:06 Re: Will PQsetSingleRowMode get me results faster? Tom Lane <[email protected]>
2025-04-04 11:41 ` Stijn Sanders <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox