Re: [HACKERS] why not parallel seq scan for slow functions - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: [HACKERS] why not parallel seq scan for slow functions
Date
Msg-id CAMkU=1yGfzU-EH2Nj+0VhCL9uR0sson=d7SnX16iNoHGJd_+1Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] why not parallel seq scan for slow functions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] why not parallel seq scan for slow functions
List pgsql-hackers
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.
 
Cheers,

Jeff

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standbyserver
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Change in "policy" on dump ordering?