Re: Thread manager

On Mon, Oct 10, 2011 at 12:06, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Sun, Oct 9, 2011 at 9:22 AM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)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"

Not sure that necessarily indicates a threadpool, but let's not get
hung up on details :-) FWIW, I think a threadpool would be very much
overkill as well - not to mention that they'd all require separate db
connections anyway, so you'd have to have all sorts of ways to limit
it etc..

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

Can you have multiple maintenance windows open at the same time, all minimized?

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

I'd find it useful, actually. But even more so if there was one
"execute now" and one "execute in the background" button, or something
like that. Being able to sticka bunch of things in a queue, knowing
they execute one by one over a single connection so I don't overload
the server, would be useful. (Which makes it even more important that
it's not a threadpool, really :D)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/