You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Haisheng Yuan (JIRA)" <ji...@apache.org> on 2019/04/07 02:53:00 UTC

[jira] [Commented] (CALCITE-299) Divide the join graph into partitions that can be optimized separately

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

Haisheng Yuan commented on CALCITE-299:
---------------------------------------

[~julianhyde] Is this still an issue?

> Divide the join graph into partitions that can be optimized separately
> ----------------------------------------------------------------------
>
>                 Key: CALCITE-299
>                 URL: https://issues.apache.org/jira/browse/CALCITE-299
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: GitHub Import
>            Priority: Major
>              Labels: github-import
>
> Currently Optiq's join optimization is exhaustive. The search space increases combinatorially, so for a query with more than about 8 joins, this is impractical. I propose a "divide and conquer" approach that tames the search space but doesn't cut out the important parts of the search space.
> First, there is a planning phase that gathers together all joins into a single mega relational expression, MultiJoinRel. 
> Then an algorithm builds a join graph, and finds a sub-graph (tree) that minimizes some cost function. Then divide that sub-graph into clusters; the nodes in a cluster are tightly connected, and the links between clusters are relatively loosely connected.
> The output of this algorithm is the graph, partitioned into moderately sized groups of nodes (say 5 - 7 maximum). Typically, in a multi-star query, each group of nodes would have a "fact table" at its center, surrounded by "dimension tables" connected by many-to-one relationships. (Fact table and dimension table are relative terms.)
> We put in place fire walls (maybe a special kind of RelNode) to prevent join transformation rules from working across clusters. Then we invoke the conventional planning process.
> ---------------- Imported from GitHub ----------------
> Url: https://github.com/julianhyde/optiq/issues/299
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels: 
> Created at: Wed Jun 11 23:24:08 CEST 2014
> State: open



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)