Re: parallelize queries containing subplans

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parallelize queries containing subplans
Date: 2017-01-24 05:29:20
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Thu, Jan 19, 2017 at 4:51 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>> During debugging I found that subplan created for below part of the
>> query is parallel_unsafe, Is it a problem or there is some explanation
>> of why it's not parallel_safe,
> Okay, so basically we don't have any mechanism to perform parallel
> scan on CTE. And, IMHO subplan built for CTE (using SS_process_ctes)
> must come along with CTE scan. So I think we can avoid setting below
> code because we will never be able to test its side effect, another
> argument can be that if we don't consider the final effect, and just
> see this subplan then by logic it should be marked parallel-safe or
> unsafe as per it's path and it will not have any side effect, as it
> will finally become parallel-unsafe. So it's your call to keep it
> either way.

Yeah, actually setting parallel_safety information for subplan from
corresponding is okay. However, in this particular case as we know
that it might not be of any use till we enable parallelism for CTE
Scan (and doing that is certainly not essential for this project).
So, I have set parallel_safe as false for CTE subplans.

With Regards,
Amit Kapila.

Attachment Content-Type Size
pq_pushdown_subplan_v4.patch application/octet-stream 9.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-01-24 05:32:56 Re: Assignment of valid collation for SET operations on queries with UNKNOWN types.
Previous Message Amit Langote 2017-01-24 05:14:08 contrib modules and relkind check