Re: assessing parallel-safety
От | Robert Haas |
---|---|
Тема | Re: assessing parallel-safety |
Дата | |
Msg-id | CA+TgmoayuYwbAmqzihOkgRVa+FF9JVfNaTABWb6DfggCMXGrbQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: assessing parallel-safety (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: assessing parallel-safety
|
Список | pgsql-hackers |
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: