Re: assessing parallel-safety

On 20 March 2015 at 13:16, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Thom Brown wrote:
>> On 18 March 2015 at 16:01, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> > On Tue, Mar 17, 2015 at 9:48 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> >> On Tue, Mar 17, 2015 at 2:26 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> >>> Neither that rule, nor its variant downthread, would hurt operator authors too
>> >>> much. To make the planner categorically parallel-safe, though, means limiting
>> >>> evaluate_function() to parallel-safe functions. That would dramatically slow
>> >>> selected queries. It's enough for the PL scenario if planning a parallel-safe
>> >>> query is itself parallel-safe. If the planner is parallel-unsafe when
>> >>> planning a parallel-unsafe query, what would suffer?
>> >>
>> >> Good point. So I guess the rule can be that planning a parallel-safe
>> >> query should be parallel-safe. From there, it follows that estimators
>> >> for a parallel-safe operator must also be parallel-safe. Which seems
>> >> fine.
>> >
>> > More work is needed here, but for now, here is a rebased patch, per
>> > Amit's request.
>>
>> This no longer applies due to changes in commit
>> 13dbc7a824b3f905904cab51840d37f31a07a9ef.
>
> You should be able to drop the pg_proc.h changes and run the supplied
> perl program. (I'm not sure that sending the patched pg_proc.h together
> with this patch is all that useful, really.)

Thanks. All patches applied and building okay.
--
Thom