trafodion-codereview mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nonstop-qfchen <...@git.apache.org>
Subject [GitHub] incubator-trafodion pull request: fix #JIRA 1449: missing end key.
Date Thu, 27 Aug 2015 16:47:04 GMT
Github user nonstop-qfchen commented on a diff in the pull request:

    https://github.com/apache/incubator-trafodion/pull/66#discussion_r38117749
  
    --- Diff: core/sql/optimizer/SimpleScanOptimizer.cpp ---
    @@ -218,25 +218,14 @@ SimpleFileScanOptimizer::isLogicalSubPartitioned() const
     SearchKey *
     SimpleFileScanOptimizer::constructSearchKey()
     {
    +  // We do not need to incude the flatten version of RANGE SPEC predicates 
    +  // to the exePreds because SearchKey is capable of handling such predicates.
    --- End diff --
    
    My intention on the comment is that SearchKey is capable of processing
    RANGE SPEC, and therefore there is no need to feed the flatten version of
    it.
    
    That complex predicates and RANGE SPEC may be partially represented in the
    SeachKey probably is a known fact.  The fix tries to address it in one
    aspect.
    
    There maybe other areas that require some work, such as
    cardinality/costing.
    
    On Thu, Aug 27, 2015 at 11:08 AM, Hans Zeller <notifications@github.com>
    wrote:
    
    > In core/sql/optimizer/SimpleScanOptimizer.cpp
    > <https://github.com/apache/incubator-trafodion/pull/66#discussion_r38113574>
    > :
    >
    > > @@ -218,25 +218,14 @@ SimpleFileScanOptimizer::isLogicalSubPartitioned() const
    > >  SearchKey *
    > >  SimpleFileScanOptimizer::constructSearchKey()
    > >  {
    > > +  // We do not need to incude the flatten version of RANGE SPEC predicates
    > > +  // to the exePreds because SearchKey is capable of handling such predicates.
    >
    > Good question, and it makes me think of two things. One is that the
    > example where MDAM can't retrieve the exact set is probably one that
    > involves complex predicates on two or more columns, while RangeSpec itself
    > is probably simple enough. But RangeSpec AND might fall into this category.
    > The second question is whether we really handle RangeSpec predicates
    > correctly in MDAM code generation.
    >
    > —
    > Reply to this email directly or view it on GitHub
    > <https://github.com/apache/incubator-trafodion/pull/66/files#r38113574>.
    >
    
    
    
    -- 
    Regards, --Qifan



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message