On 9 April 2015 at 00:12, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Wed, Apr 8, 2015 at 3:30 PM, David Rowley <dgrowle...@gmail.com> wrote: > > > > On 8 April 2015 at 15:46, Amit Kapila <amit.kapil...@gmail.com> wrote: > >> > >> I think there is always a chance that resources (like parallel-workers) > >> won't be available at run-time even if we decide about them at > >> executor-start phase unless we block it for that node's usage and OTOH > >> if we block it (by allocating) those resources during executor-start > phase > >> then we might end up blocking it too early or may be they won't even get > >> used if we decide not to execute that node. On that basis, it seems to > >> me current strategy is not bad where we decide during planning time and > >> later during execution time if not all resources (particularly > parallel-workers) > >> are not available, then we use only the available one's to execute the > plan. > >> Going forward, I think we can improve the same if we decide not to > shutdown > >> parallel workers till postmaster shutdown once they are started and > >> then just allocate them during executor-start phase. > >> > >> > > > > Yeah, but what about when workers are not available in cases when the > plan was only a win because the planner thought there would be lots of > workers... There could have been a more optimal serial plan already thrown > out by the planner which is no longer available to the executor. > > > > That could also happen even if we decide in executor-start phase. > Yes this is true, but if we already have the most optimal serial plan, then there's no issue. > I agree that there is a chance of loss incase appropriate resources > are not available during execution, but same is true for work_mem > as well for a non-parallel plan. I think we need some advanced way > to handle the case when resources are not available during execution > by either re-planing the statement or by some other way, but that can > also be done separately. > > There was some talk of re-planning queries over on the Removing INNER JOINs thread: http://www.postgresql.org/message-id/CA+TgmoaHi8tq7haZCf46O_NUHT8w=p0z_n59dc0yojfmucs...@mail.gmail.com Regards David Rowley
