tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jihoon Son (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAJO-415) Some complex queries causes NPE and unlimited recursions.
Date Sun, 15 Dec 2013 16:05:06 GMT

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

Jihoon Son commented on TAJO-415:
---------------------------------

Thanks. 
It will be very interesting!

> Some complex queries causes NPE and unlimited recursions.
> ---------------------------------------------------------
>
>                 Key: TAJO-415
>                 URL: https://issues.apache.org/jira/browse/TAJO-415
>             Project: Tajo
>          Issue Type: Bug
>          Components: distributed query plan, planner/optimizer
>            Reporter: Hyunsik Choi
>            Assignee: Hyunsik Choi
>            Priority: Critical
>             Fix For: 0.8-incubating
>
>         Attachments: TAJO-415.patch
>
>
> This patch fixes the following critical bugs.
> * GreedyHeuristicJoinOrder::getCost may cause unlimited recursion.
>  ** getCost() method is a recursion function.
>  ** getCost() method has not considered all logical operators, so some logical operators
are processed in a default case which is implemented incorrectly. It causes unlimited recursion.
> * ProjectionPushDown rewrite rule tries to push down necessary target lists to all subqueries.

>  ** It may cause some problem in a subquery which includes a group-by operator because
there is no unnecessary target lists in the subquery, including a group-by operator. This
patch prevents ProjectionPushDown to push down target lists to some subqueries.
> * Task::setLogicalPlan does not traverse descendant nodes of TableSubQueryNode.
>  ** So, it have missed some logical operators.
> * SubQuery::getInputVolume may cause NPE when a logical plan includes a bushy join tree.
>  ** In the past, a distributed plan is generated from left-deep join tree. At that time,
the volume of join relations are computed directly from joined results (left) or relation
nodes (right). However, for bushy join, getInputVolume() has some cases to estimate intermediate
data volume prior to actual joins.
> * FilterPushDown tries to validate outer join's null suppression. This code assumes that
outer join's input relations are only ScanNodes.
>  ** Actually, outer join's input relations can be either ScanNode or TableSubQueryNode.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message