[jira] [Commented] (HAWQ-161) Port GPDB planner fixes to HAWQ

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HAWQ-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004461#comment-15004461 ] 

ASF GitHub Bot commented on HAWQ-161:
-------------------------------------

GitHub user hsyuan opened a pull request:

    https://github.com/apache/incubator-hawq/pull/110

    HAWQ-161. Port GPDB planner fixes to HAWQ

    Port GPDB planner fixes to HAWQ

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/hsyuan/incubator-hawq HAWQ-161

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-hawq/pull/110.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #110
    
----
commit 8c1f5cd316ee5deef086ba01072649ea8c9fcf94
Author: Kenan Yao <ky...@pivotal.io>
Date:   2014-11-24T03:31:47Z

    HAWQ-161. Port GPDB planner fixes to HAWQ
    Query crashed with segmentation fault with optimizer=off.
    
    The crash happened in executor, while the root cause is in planner. The planner
    mistakenly believe that, when both the root node of subplan and the corresponding
    main plan node are executed in QD, there is no need to call function
    ParallelizeCorrelatedSubPlan. While, actually, in this situation presented in
    the JIRA, both the main plan node Window and subplan node Agg are executed in QD,
    we still need to do the subplan parallelization, otherwise, the SeqScan node
    cannot get the parameter from main plan, because they are in different slices.

commit d89b3c28e8448bdcc4c41a0c1fdbec2c04dd38d5
Author: Kenan Yao <ky...@pivotal.io>
Date:   2014-12-24T06:17:24Z

    HAWQ-161. Port GPDB planner fixes to HAWQ
    Query Crashes with "Error on receive...server closed the connection unexpectedly".
    
    Same issue as MPP-24563; after applying the fix for MPP-24563, this case still
    failed because of assert failure in apply_shareinput_xslice. Root cause is that
    cdbparallelize changes the plan but does not update the flow of the upper nodes,
    therefore, once ParallelizeCorrelatedSubPlanMutator takes action, then we cannot
    gurantee the correctness of the upper nodes' flow. Fix is to update the flow after
    transforming the lower nodes. Note that, the function
    ParallelizeCorrelatedSubPlanUpdateFlowMutator currently only handles the three
    known situations, if more cases of this kind found, just twickle that function
    can solve the problem.

commit 13f165fe2c5b78ed90092543f1616039446fd1fb
Author: Kenan Yao <ky...@pivotal.io>
Date:   2015-11-12T23:13:16Z

    HAWQ-161. Port GPDB planner fixes to HAWQ
    Planner generated unnecessary motion node for nested subplan which scan catalog table.

commit 06a85b6e32bf1388036d88f88130ddcd4d417530
Author: Kenan Yao <ky...@pivotal.io>
Date:   2015-11-12T23:36:37Z

    HAWQ-161. Port GPDB planner fixes to HAWQ
    SIGSEGV happened in HashJoin.
    
    This issue was caused by a previous fix for MPP-12637, and therefore a wrong
    plan was generated for query like:
    
    select c.relname from pg_class c where c.relname in (select b.table_name from
    information_schema.tables b where c.relname like '%id%');
    
    The RC for MPP-25724 is that, planner believes the subquery should not be pulled
    up because it contains CoerceToDomain node, while actually the subquery MUST be
    pulled up, otherwise HashJoin would fail.
    
    However, after I make planner pull up that subquery, the problem in MPP-12637
    would happen again, i.e, for query like below, planner would error out.
    
    select * FROM (select attnum::information_schema.cardinal_number from
    pg_attribute where attnum > 0) q where attnum = 4;
    
    The key problem here is the order of quals, including the pulled up ones, i.e,
    the order of "attnum = 4" and "attnum > 0", my solution is replacing
    RangeTblRef of pulled up subquery with the resulting FromExpr, which is
    consistent with PostgreSQL's style, instead of separately appending the fromlist
    and quals of the resulting FromExpr to the parent query in previous GPDB.
    
    The final problem here now is in function deconstruct_jointree(). Previous
    assumption is that the quals must be compatible with the same level relids,
    however for query #1 mentioned above, we should break this assumption, so I
    introduced the PostponedQual feature of PostgreSQL. Meanwhile, we should make
    some corresponding changes in pull_up_simple_query to appropriately do the
    ResolveNew procedure now.

----


> Port GPDB planner fixes to HAWQ
> -------------------------------
>
>                 Key: HAWQ-161
>                 URL: https://issues.apache.org/jira/browse/HAWQ-161
>             Project: Apache HAWQ
>          Issue Type: Improvement
>          Components: Optimizer
>            Reporter: Haisheng Yuan
>            Assignee: Amr El-Helw
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)