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=1wkJ0UsXoqSJcy-70t=05JP7vsGYgQ3cMst246OOM6ykA@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  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Andrew Gierth
Date:
Subject: [HACKERS] close_ps, NULLs, and DirectFunctionCall
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Boom filters for hash joins (was: A design for amcheckheapam verification)