Re: assessing parallel-safety

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: assessing parallel-safety
Дата
Msg-id CA+TgmobJSuefiPOk6+i9WERUgeAB3ggJv7JxLX+r6S5SYydBRQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: assessing parallel-safety  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: assessing parallel-safety  (Amit Kapila <amit.kapila16@gmail.com>)
Re: assessing parallel-safety  (Thom Brown <thom@linux.com>)
Список pgsql-hackers
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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: parallel mode and parallel contexts