Re: why not parallel seq scan for slow functions
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-07-25T01:13:46Z
Lists: pgsql-hackers
On Mon, Jul 24, 2017 at 9:21 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Sat, Jul 22, 2017 at 8:53 PM, Amit Kapila <amit.kapila16@gmail.com> > wrote: >> >> On Thu, Jul 13, 2017 at 7:38 AM, Amit Kapila <amit.kapila16@gmail.com> >> wrote: >> > On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes <jeff.janes@gmail.com> >> > wrote: >> >> >> >> >> >> >> >> Setting parallel_workers to 8 changes the threshold for the parallel to >> >> even >> >> be considered from parellel_tuple_cost <= 0.0049 to <= 0.0076. So it >> >> is >> >> going in the correct direction, but not by enough to matter. >> >> >> > >> > You might want to play with cpu_tuple_cost and or seq_page_cost. >> > >> >> I don't know whether the patch will completely solve your problem, but >> this seems to be the right thing to do. Do you think we should stick >> this for next CF? > > > It doesn't solve the problem for me, but I agree it is an improvement we > should commit. > Okay, added the patch for next CF. -- 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