Re: [HACKERS] why not parallel seq scan for slow functions
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
Дата | |
Msg-id | CAA4eK1LtQ8dVHhO+s4PGj_A-ZMCnXOziF1QPn-R1PGxRxHJDyw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] why not parallel seq scan for slow functions (Jeff Janes <jeff.janes@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: