Re: [HACKERS] why not parallel seq scan for slow functions

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] why not parallel seq scan for slow functions
Дата
Msg-id CAMkU=1yGfzU-EH2Nj+0VhCL9uR0sson=d7SnX16iNoHGJd_+1Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] why not parallel seq scan for slow functions  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] why not parallel seq scan for slow functions  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standbyserver
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Change in "policy" on dump ordering?