On Tue, May 16, 2017 at 8:18 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > In the current state of the patch, the main backend tries to start the > extra workers only when there is no tuples that are available from the > available workers. I feel that the invocation for more workers doesn't > do for every tuple.
Well, the point is, the frequency with which the leader will try to acquire more workers is going to be highly variable with your patch, and might sometimes be extremely frequent. It depends on the timing of the workers and of the leader, and I don't think that's something we want to depend on here.
Ok.
> Another background process logic can produce a fair distribution of > workers to the parallel queries. In this case also, the backend should > advertise only when the allotted workers are not enough, this is because > there may be a case where the planned workers may be 5, but because > of other part of the query, the main backend is feed by the tuples just by > 2 workers, then there is no need to provide extra workers.
That's true, but I think taking it into account might be difficult. > The another background process approach of wait interval to reassign > more workers after an interval period doesn't work for the queries that > are getting finished before the configured time of the wait. May be we > can ignore those scenarios?
I think we can ignore that. We can still help a lot of cases, and queries with very short run times obviously aren't being seriously hurt by the lack of full parallelism.
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 will give a try and see how easy to implement the same.
