Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
Date
Msg-id CAA4eK1JY5jK_WmHFX2xYXHD9atGD3C3vYpwdZnOGdoY0oy3Yzw@mail.gmail.com
Whole thread
In response to Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
List pgsql-hackers
On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
>
> > Could you answer my question about whether adjust_appendrel_attrs()
> > might translate Vars into non-Vars?
>
> Yes, absolutely.

Isn't this true only for UNION ALL cases and not for inheritance child relations (at least that is what seems to be mentioned in comments for translated_vars in AppendRelInfo)?   If that is right, then I think there shouldn't be a problem w.r.t parallel plans even if adjust_appendrel_attrs() translate Vars into non-Vars, because for UNION ALL it seems parent rels rtekind is RTE_SUBQUERY and we consider such rels as parallel unsafe (see set_rel_consider_parallel()).  So it doesn't matter even if child rels target list contains any parallel unsafe expression, as we are not going to create parallel paths for such relations.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Parallel safety tagging of extension functions
Next
From: Amit Kapila
Date:
Subject: Re: Reviewing freeze map code