Jeroen T. Vermeulen wrote:
> Adriaan van Os wrote:
>> I couldn't find anything in the libpq interfaces that identifies the
>> current progress of an
>> asynchronous query as a percentage of the estimated total query time. So,
>> unless I missed
>> something, I would like to file this as a feature request.
>>
>> The idea behind this, of course, is to show a progress bar in the user
>> interface of the client
>> application as soon as the query takes longer than say 1 second.
>
> One way to do this would be to use a cursor, and only receive batches of
> (say) a hundred or a thousand rows at a time. In that case you might not
> even want to bother with asynchronous execution at all.
>
> It may take some extra work for your program to handle its data in chunks.
> Then again, for many programs it's not necessary to hold all of a result
> set in memory at the same time. In that case you may see reduced memory
> usage if you request one chunk of data through a cursor, process it, then
> request the next batch.
>
> Doing that will take longer overall but give you faster initial response
> time. If you want to keep the overall time low, and you do a lot of
> processing per batch, you may still want to request your batches
> asynchronously just so your program can process one batch of data while
> the server is retrieving the next.
Thanks for your reply and the idea to process data in chunks. Still, I feel that a workaround for
some situations (that may not work in others) is not in general a good replacement for a
fundamental feature, as keeping the user informed is one of principles of User Interface design
<http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGHIDesign/chapter_5_section_2.html>.
Besides, when more than one user is connected, multiple SQL commands may behave different than a
single SQL command (<http://www.postgresql.org/docs/8.1/static/transaction-iso.html>)
Regards,
Adriaan van Os
