On Sat, Dec 6, 2014 at 1:50 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think we have access to this information in planner (RelOptInfo -> pages), > if we want, we can use that to eliminate the small relations from > parallelism, but question is how big relations do we want to consider > for parallelism, one way is to check via tests which I am planning to > follow, do you think we have any heuristic which we can use to decide > how big relations should be consider for parallelism?
Surely the Path machinery needs to decide this in particular cases based on cost. We should assign some cost to starting a parallel worker via some new GUC, like parallel_startup_cost = 100,000. And then we should also assign a cost to the act of relaying a tuple from the parallel worker to the master, maybe cpu_tuple_cost (or some new GUC). For a small relation, or a query with a LIMIT clause, the parallel startup cost will make starting a lot of workers look unattractive, but for bigger relations it will make sense from a cost perspective, which is exactly what we want. There are probably other important considerations based on goals for overall resource utilization, and also because at a certain point adding more workers won't help because the disk will be saturated. I don't know exactly what we should do about those issues yet, but the steps described in the previous paragraph seem like a good place to start anyway. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
