From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assessing parallel-safety |
Date: | 2015-02-12 21:10:35 |
Message-ID: | CA+TgmoYiAZJcguYMLmeqeGJzAda+uTYRsK3v_gRP7hFAd2hx+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 12, 2015 at 3:52 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ravi Kiran | 2015-02-12 21:14:05 | Re: enabling nestedloop and disabling hashjon |
Previous Message | Jim Nasby | 2015-02-12 21:04:39 | Re: enabling nestedloop and disabling hashjon |