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=1wkJ0UsXoqSJcy-70t=05JP7vsGYgQ3cMst246OOM6ykA@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 Tue, Sep 19, 2017 at 9:15 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Wed, Sep 20, 2017 at 3:05 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Sep 19, 2017 at 1:17 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>>
>> On Thu, Sep 14, 2017 at 3:19 PM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>> > The attached patch fixes both the review comments as discussed above.
>
>
> that should be fixed by turning costs on the explain, as is the tradition.
>

Right.  BTW, did you get a chance to run the original test (for which
you have reported the problem) with this patch?

Yes, this patch makes it use a parallel scan, with great improvement.  No more having to \copy the data out, then run GNU split, then run my perl or python program with GNU parallel on each file.  Instead I just have to put a pl/perl wrapper around the function.

(next up, how to put a "create temp table alsdkfjaslfdj as" in front of it and keep it running in parallel)

Thanks,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: [HACKERS] close_ps, NULLs, and DirectFunctionCall
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Boom filters for hash joins (was: A design for amcheckheapam verification)