Re: Thread manager

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.

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

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

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

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

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

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