Skip site navigation (1) Skip section navigation (2)

Re: [patch] libpq one-row-at-a-time API

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Leon Smith <leon(dot)p(dot)smith(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] libpq one-row-at-a-time API
Date: 2012-07-31 01:59:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 7/30/2012 8:11 PM, Leon Smith wrote:
> One other possibility,  Tom Lane fretted ever so slightly about the use
> of malloc/free per row... what about instead of PQsetSingleRowMode,  you
> have PQsetChunkedRowMode that takes a chunkSize parameter.   A chunkSize
> <= 0 would be equivalent to what we have today,   a chunkSize of 1 means
> you get what you have from PQsetSingleRowMode,  and larger chunkSizes
> would wait until n rows have been received before returning them all in
> a single result.      I don't know that this suggestion is all that
> important, but it seems like an obvious generalization that might
> possibly be useful.

It is questionable if that actually adds any useful functionality. Any 
"collecting" of multiple rows will only run the risk to stall receiving 
the following rows while processing this batch. Processing each row as 
soon as it is available will ensure making most use network buffers.

Collecting multiple rows, like in the FETCH command for cursors does, 
makes sense when each batch introduces a network round trip, like for 
the FETCH command. But does it make any sense for a true streaming mode, 
like what is discussed here?


Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

In response to


pgsql-hackers by date

Next:From: Leon SmithDate: 2012-07-31 02:31:44
Subject: Re: [patch] libpq one-row-at-a-time API
Previous:From: Leon SmithDate: 2012-07-31 00:11:26
Subject: Re: [patch] libpq one-row-at-a-time API

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group