Re: [HACKERS] Increasing parallel workers at runtime - Mailing list pgsql-hackers

From Rafia Sabih
Subject Re: [HACKERS] Increasing parallel workers at runtime
Date
Msg-id CAOGQiiNFOH7h61BsD2zkck=TgrYaX6J8cVmS=0MQ_iO8xV9fmw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Increasing parallel workers at runtime  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, May 23, 2017 at 4:41 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

> Isn't this point contradictory?  Basically, on one side you are
> suggesting to calculate additional workers (work_remaining) based on
> selectivity and on another side you are saying that it will fix
> estimation errors.  IIUC, then you are talking about some sort of
> executor feedback to adjust a number of workers which might be a good
> thing to do but I that is a different problem to solve.  As of now, I
> don't think we have that type of mechanism even for non-parallel
> execution.
>
Yes, I am talking of a executor feedback mechanism sort of a thing.
For non parallel execution it's a lot more challenging since the
execution plan might need to be changed in the runtime, but in
parallel query case only addition/subtraction of workers is to be
dealt, which appears to be a less complex thing.
Why I am thinking in this direction is because in my experience it
seems very easy to regress with more workers when over-estimation is
done and this runtime calculation of workers can mitigate it largely.
However, I understand that this might require more proof than my
experience alone. Let's see if anybody else shares my gut feeling. :)

-- 
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)
Next
From: Amit Kapila
Date:
Subject: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is*still* broken)