Re: Increasing parallel workers at runtime

On Wed, May 17, 2017 at 5:45 AM, Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com> wrote:
>
>
> On Wed, May 17, 2017 at 2:35 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>
>
> Ok. In this approach, we need to share some of the gatherstate structure
> members in the shared memory to access by the other background process
> or some better logic to update these details whenever a new worker gets
> allotted.
>

I don't think you need to share that stuff as we initialize the
dsm/queues based on planned workers. I think one thing you might want
to consider is to see if this new background worker can detect whether
the query has already finished before launching workers. Yet another
way to look at this problem is to have an idea of Alternative
non-parallel plans corresponding to parallel plans. As of now, we
only have one plan during execution of parallel plan and if we don't
have enough workers, we have no choice but to proceed with that plan,
however, if we have some Alternative plan which is non-parallel, it
might be better to use the same if we can't allocate enough number of
workers for the query. IIRC, this has been discussed previously
during the development of Parallel Sequential Scan patch and I think
some other databases uses some similar technique for this problem.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com