Re: Thread manager

On Tue, 2011-10-04 at 11:01 +0100, Dave Page wrote:
> On Mon, Oct 3, 2011 at 9:35 PM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info> wrote:
> > Hi,
> >
> > While working on Vladimir's patch, it reminded me of an idea I wanted to
> > share.
> >
> > Right now, when you launch a dump, or a VACUUM, the UI kinda sucks
> > because it puts you on another tab, still in the same dialog, and you
> > can't be sure you can do something else while the work is ongoing. It'll
>
> You should be able to - the busy cursor should only be active for the
> busy dialogue. Switch to another window and you should get a non-busy
> cursor which indicates you can do stuff.
>

Yeah. It's just a cursor though.

> > 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.

> > 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.

> > 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.

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).

> > We could use if for the
> > "copy table" patch. We could also use it for the dump/restore dialog.
> > And there are probably more things to do with it. We could probably add
> > buttons to pause/resume waiting jobs, and to drop jobs.
>
> I'm afraid I cannot see how this is a better design.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com