Re: Thread manager - Mailing list pgadmin-hackers

On Sun, Oct 9, 2011 at 9:22 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>
>> > worse with Vladimir's patch as there is no UI at all to show the
>> > progress on the copy (if you copy more than one table of course).
>>
>> There needs to be some status indication, even if it's just an
>> animation (maybe busy cursor over the dialogue) and text that says
>> "Copying table 1...",  "Copying table 2..." etc.
>>
>
> AFAICT, you only have the final status.

Some progress text would certainly be sensible - this sort of
operation could take hours.

>> > I was a few weeks ago at a customer's office, and he showed me a nice UI
>> > of a tool (unfortunately, I don't remember its name) that allowed him to
>> > queue some jobs. So I wondered if we could do the same. When you're in
>> > the VACUUM dialog, and click OK, it adds a job in the jobs list, and a
>> > thread will catch it as soon as it is available for a new job. The UI
>>
>> We don't need to use a thread pool to save resources for this kind of
>> thing, even if running on a net book - we can just launch a thread as
>> needed and let the OS deal with resource management. I can't imagine
>> the user will be able to start enough task threads that even a Windows
>> 95 system couldn't cope.
>>
>
> I'm not talking about performance. I'm talking about UI. I'm talking
> about adding a single UI to handle many operations.

You were talking about a thread pool, which I think is totally
unnecessary: "a thread will catch it as soon as it is available for a
new job"

>> > could be as simple as a new pane in frmMain, with a listbox which
>> > contains the list of job, and their status.
>>
>> All of these threads that we have at the moment are returning data to
>> the UI for display (in theory, as work progresses, but I'm aware that
>> doesn't work everywhere). Are you suggesting that we would get rid of
>> that UI, and make the user move to another window, display the
>> appropriate pane (something like this wouldn't be visible by default),
>> and then double-click the appropriate row to view the output? What
>> about purging old data? How would we decide when to remove something
>> from the list?
>>
>
> Let's say you want to do a "VACUUM FULL" (yeah, I know, crazy idea).
> Now, you'll have the Maintenance window working, and you can get to the
> browser window to continue (if you can) your work.

If you can't, then we have a bug in the current code. You should be
able to minimise the Maintenance window and carry on.

> What I suggest is adding a pane in the browser window. So, you open the
> Maintenance window, do your stuff to launch a VACUUM FULL. Then, the
> Maintenance window is closed, the "Jobs" pane is opened (if it wasn't
> already), a new job appears stating that it is a VACUUM FULL job on
> database/table whatever, and that the job is running. We can probably
> add more infomations (for example, the duration, if it's blocked by
> another session, etc.) and more actions (kill it, pause it, resume it).

Yeah, I understand what you're proposing. I've seen similar things in
other products in years gone by. I don't think there's any need for us
to do anything like that though - I think it would take a lot of
engineering and buy little. More importantly, I think it will be
detrimental to the user experience, as a task that was once confined
to one dialogue now is started from one, and ends on separate window.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company