Re: pgsql: Fix cardinality estimates for parallel joins.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <rhaas(at)postgresql(dot)org>
Cc: pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Fix cardinality estimates for parallel joins.
Date: 2017-01-16 12:23:52
Message-ID: CAA4eK1KPm8RYa1Kun3ZmQj9pb723b-EFN70j47Pid1vn3ByquA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Jan 14, 2017 at 12:07 AM, Robert Haas <rhaas(at)postgresql(dot)org> wrote:
> Fix cardinality estimates for parallel joins.
>

+ /*
+ * In the case of a parallel plan, the row count needs to represent
+ * the number of tuples processed per worker.
+ */
+ path->rows = clamp_row_est(path->rows / parallel_divisor);
}

path->startup_cost = startup_cost;
@@ -2014,6 +1996,10 @@ final_cost_nestloop(PlannerInfo *root, NestPath *path,
else
path->path.rows = path->path.parent->rows;

+ /* For partial paths, scale row estimate. */
+ if (path->path.parallel_workers > 0)
+ path->path.rows /= get_parallel_divisor(&path->path);

Isn't it better to call clamp_row_est in join costing functions as we
are doing in cost_seqscan()? Is there a reason to keep those
different?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Magnus Hagander 2017-01-16 12:58:31 pgsql: Make pg_basebackup use temporary replication slots
Previous Message Fujii Masao 2017-01-16 09:56:14 pgsql: Fix typos in comments.

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-01-16 12:46:46 Re: Support for pg_receivexlog --format=plain|tar
Previous Message Magnus Hagander 2017-01-16 12:12:23 Re: Support for pg_receivexlog --format=plain|tar