On Wed, Mar 12, 2014 at 10:57:03AM +0000, matshyeq wrote:
> On Wed, Mar 12, 2014 at 9:30 AM, Marko Kreen <markokr@gmail.com> wrote:
> > This option would not make sense as you are not "fetching" anything,
> > full resultset is being streamed from server over TCP connection.
>
> Well, I don't know what "streamed" exactly means here.
> If server pushes sequentially all the data not asking client if ready to
> receive then that's what the issue is about.
This problem is handled in kernel's TCP stack - it will slow down
the connection if userspace does not read fast enough.
IOW, don't worry about it.
> If client asks server for another chunk each time it has received previous
> one then to me it's implicit 'fetching' scenario where user/developer
> doesn't have an option to define fetch size.
This is how it is usually implemented and configurable fetch size
is indeed useful in such situation. But it requires separate round-trip
for each chunk so single-row-mode is superior method for processing
large queries without huge buffers.
> > > - is it/would it be possible to add corresponding option to pgAdmin to
> >
> > limit initially (and each subsequently) returned rows in Query Tool by
> >
> > custom defined max value?
> >
>
> > It could close connection in the middle of resultset but that seems like
> > bad idea. LIMIT N or FETCH N are better for such task.
>
> I don't see why? I can't think of any single SQL tool I've been working
> with that didn't have this functionality, really.
Yeah, I see no reason pgAdmin cannot implement it. Implementing
such feature with transparently adding LIMIT or FETCH is better.
PQsetSingleRowMode() is not meant for partial resultsets, but it can
be used if you accept the downsides.
--
marko
