Date: Fri, 15 Sep 2006 14:56:33 +0200
From: Adriaan van Os <postgres@microbizz.nl>
Subject: Re: Progress of asynchronous queries
In-reply-to: <450A6A87.2030808@microbizz.nl>
To: pgsql-interfaces@postgresql.org
Message-id: <450AA301.9020408@microbizz.nl>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516)
References: <450A6A87.2030808@microbizz.nl>

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