Re: why not parallel seq scan for slow functions
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>,
Thomas Munro <thomas.munro@enterprisedb.com>, Amit Khandekar <amitdkhan.pg@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-11-09T08:47:48Z
Lists: pgsql-hackers
Attachments
- parallel_paths_include_tlist_cost_v6.patch (application/octet-stream) patch v6
On Wed, Nov 8, 2017 at 6:48 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Nov 8, 2017 at 7:26 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> We do want to generate it later when there isn't inheritance involved, >> but only if there is a single rel involved (simple_rel_array_size >> <=2). The rule is something like this, we will generate the gather >> paths at this stage only if there are more than two rels involved and >> there isn't inheritance involved. > > Why is that the correct rule? > > Sorry if I'm being dense here. I would have thought we'd want to skip > it for the topmost scan/join rel regardless of the presence or absence > of inheritance. > I think I understood your concern after some offlist discussion and it is primarily due to the inheritance related check which can skip the generation of gather paths when it shouldn't. So what might fit better here is a straight check on the number of base rels such that allow generating gather path in set_rel_pathlist, if there are multiple baserels involved. I have used all_baserels which I think will work better for this purpose. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Rewrite the code that applies scan/join targets to paths.
- 11cf92f6e2e1 11.0 landed
-
Teach create_projection_plan to omit projection where possible.
- d7c19e62a8e0 11.0 landed
-
Make the upper part of the planner work by generating and comparing Paths.
- 3fc6e2d7f5b6 9.6.0 cited