Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)

On Thursday, September 20, 2012 7:35 PM Kohei KaiGai wrote:
2012/9/20 Amit Kapila <amit(dot)kapila(at)huawei(dot)com>:
> On Thursday, September 20, 2012 1:44 AM Simon Riggs wrote:
> On 12 September 2012 04:30, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> On Tuesday, September 11, 2012 9:09 PM Alvaro Herrera wrote:
>> Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400
> 2012:
>>
>>>>>> We have some use cases for this patch, when can you post
>>>>>> a new version? I would test and review it.
>>
>>>>> What use cases do you have in mind?
>>
>>>> Wouldn't it be helpful for some features like parallel query in
future?
>
>>> Trying to solve that is what delayed this patch, so the scope of this
>>> needs to be "permanent daemons" rather than dynamically spawned worker
>>> tasks.
>
>> Why can't worker tasks be also permanent, which can be controlled
through
>> configuration. What I mean to say is that if user has need for parallel
>> operations
>> he can configure max_worker_tasks and those many worker tasks will get
>> created.
>> Otherwise without having such parameter, we might not be sure whether
such
>> deamons
>> will be of use to database users who don't need any background ops.
>
>> The dynamism will come in to scene when we need to allocate such
daemons
>> for particular ops(query), because
>> might be operation need certain number of worker tasks, but no such
task
>> is available, at that time it need
>> to be decided whether to spawn a new task or change the parallelism in
>> operation such that it can be executed with
>> available number of worker tasks.
>

> I'm also not sure why "permanent daemons" is more difficult than
dynamically
> spawned daemons,

I think Alvaro and Simon also felt "permanent daemons" is not difficult and
is the right way to go,
that’s why the feature is getting developed on those lines.

With Regards,
Amit Kapila.