On Thu, May 12, 2016 at 7:46 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On further analysis, I think I know what is going on in the original bug
> report.  We add the Vars (build_base_rel_tlists) and PlaceholderVars
> (add_placeholders_to_base_rels()) to each relations (RelOptInfo) target
> during qurey_planner and the Subplans are added as PlaceHolderVars in target
> expressions.  Now while considering whether a particular rel can be parallel
> in set_rel_consider_parallel(), we don't check the target expressions to
> allow the relation for parallelism.  I think we can prohibit the relation to
> be considered for parallelism if it's target expressions contain any
> parallel restricted clause.  Fix on those lines is attached with this mail.
>
> Thanks to Dilip Kumar for helping me in narrowing down this particular
> problem.  We were not able to generate the exact test, but I think the above
> theory is sufficient to prove that it can cause a problem as seen in the
> original bug report.

I could be wrong, but I thought that the target list for an expression
would always contain only Vars at this stage.  Non-default tlists get
injected at the end of scan/join planning.  Am I wrong?

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to