On Wed, May 17, 2017 at 5:45 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > > On Wed, May 17, 2017 at 2:35 AM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
