[
https://issues.apache.org/jira/browse/PHOENIX-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16399053#comment-16399053
]
Maryann Xue commented on PHOENIX-4616:
--------------------------------------
As one of the potential improvements I mentioned earlier, we might want to find
a global optimal for some query plans, so I think it'd be good to keep the
optimization logic in one place and independent of QueryPlan for the long-term
goal.
At this point, we only have three different situations to handle for all kinds
of QueryPlan:
# BaseQueryPlan
# Joins
# All others
Ultimately we'd like to make it only two branches: 1. BaseQueryPlan and 2.
Non-BaseQueryPlan. Although we do have to separate BaseQueryPlan from other
kinds of QueryPlan, yet I don't think it's worth using a visitor either. Shall
I just push this in as it is now and figure out what we should do as we expand
the optimization logic?
> Move join query optimization out from QueryCompiler into QueryOptimizer
> -----------------------------------------------------------------------
>
> Key: PHOENIX-4616
> URL: https://issues.apache.org/jira/browse/PHOENIX-4616
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Priority: Major
> Attachments: PHOENIX-4616.patch
>
>
> Currently we do optimization for join queries inside QueryCompiler, which
> makes the APIs and code logic confusing, so we need to move join optimization
> logic into QueryOptimizer.
> Similarly, but probably with a different approach, we need to optimize UNION
> ALL queries and derived table sub-queries in QueryOptimizer.optimize().
> Please also refer to this comment:
> https://issues.apache.org/jira/browse/PHOENIX-4585?focusedCommentId=16367616&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16367616
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
