[
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 <k...@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 <k...@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 <k...@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 <k...@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)
