Re: assessing parallel-safety

On 18 March 2015 at 16:01, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 17, 2015 at 9:48 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Mar 17, 2015 at 2:26 AM, Noah Misch <noah@leadboat.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.

-- 
Thom