You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@doris.apache.org by GitBox <gi...@apache.org> on 2021/03/31 09:16:44 UTC

[GitHub] [incubator-doris] EmmyMiao87 opened a new pull request #5588: Colocate set operation

EmmyMiao87 opened a new pull request #5588:
URL: https://github.com/apache/incubator-doris/pull/5588


   ## Proposed changes
   
       [Colocate plan][Step4] Colocate set operation node
   
       The set operation node (such as union, intersect, except) could colocate
       when data partition of all of child fragments are same as the input partition of set operation node.
       At the same time, the child node of the set operation is greater than one.
       Therefore, only scan nodes between different nodes in a colocate group can colocate.
   
       The planning of the collection node after colocate is as follows:
       |   0:INTERSECT                                                                    |
       |   |  colocate=true                                                               |
       |   |----2:OlapScanNode                                                            |
       |   |       TABLE: t2                                                              |
       |   |----3:OlapScanNode                                                            |
       |   |       TABLE: t3                                                              |
       |   1:OlapScanNode                                                                 |
       |      TABLE: t1                                                                   |
       From the above figure, we can see that the intersect node is absorbed by the child nodes,
       and the exchange node is no longer needed between the three child nodes and the intersect node.
   
       This pr also supports the absorption of a single node.
       When the child node itself has only one instance, the upper node will be directly absorbed into the lower node.
       This optimization can reduce unnecessary data transmission.
   
   ## Types of changes
   
   What types of changes does your code introduce to Doris?
   _Put an `x` in the boxes that apply_
   
   - [ ] Bugfix (non-breaking change which fixes an issue)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
   - [ ] Documentation Update (if none of the other choices apply)
   - [ ] Code refactor (Modify the code structure, format the code, etc...)
   
   ## Checklist
   
   _Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code._
   
   - [ ] I have created an issue on (Fix #ISSUE) and described the bug/feature there in detail
   - [x] Compiling and unit tests pass locally with my changes
   - [ ] I have added tests that prove my fix is effective or that my feature works
   - [ ] If these changes need document changes, I have updated the document
   - [ ] Any dependent changes have been merged
   
   ## Further comments
   
   ISSUE and unit test are comming.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org