Re: assessing parallel-safety

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: assessing parallel-safety
Дата
Msg-id CA+TgmoYiAZJcguYMLmeqeGJzAda+uTYRsK3v_gRP7hFAd2hx+Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: assessing parallel-safety  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: assessing parallel-safety  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Feb 12, 2015 at 3:52 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Probably not, because many queries will scan multiple relations, and
>> we want to do all of this work just once per query.
>
> By this, do you mean to say that if there is any parallel-unsafe
> expression (function call) in query, then we won't parallelize any
> part of query, if so why is that mandatory?

Because of stuff like set_config() and txid_current(), which will fail
outright in parallel mode.  Also because the user may have defined a
function that updates some other table in the database, which will
also fail outright if called in parallel mode.  Instead of failing, we
want those kinds of things to fall back to a non-parallel plan.

> Can't we parallelize scan on a particular relation if all the expressions
> in which that relation is involved are parallel-safe

No, because the execution of that node can be interleaved in arbitrary
fashion with all the other nodes in the plan tree.  Once we've got
parallel mode active, all the related prohibitions apply to
*everything* we do thereafter, not just that one node.

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



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: enabling nestedloop and disabling hashjon
Следующее
От: Ravi Kiran
Дата:
Сообщение: Re: enabling nestedloop and disabling hashjon