> 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.
Again, this is something 'at discretion' of the pqlib library therefore not sure how 'slowing down' really works in different scenarios, like ie. server and app client on the same machine? Still see quite a value in specifying this explicitly (like JDBC does), which BTW I did by using CURSOR as a workaround.
> 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.
I wouldn't worry about this (round trips) myself - at the end of the day client decides when and how much to pull. Also, in the datawarehouse area, we consciously tune this parameter for each DB source individually which is considered very (and good!) common practice.
> > > - 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.
Don't fully agree with last statement. FETCH is WAY better and more functional than LIMIT.
PQsetSingleRowMode() is not meant for partial resultsets, but it can
be used if you accept the downsides.
Given the 'discretion mode' I'm still not sure if that's a proper and elegant way to meet the requirement. Maybe it is? Anyway, This is just me, an end user giving you, the PostgreSQL maintaining developers a chance to hear 'the voice of the customer'
