phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4616) Move join query optimization out from QueryCompiler into QueryOptimizer
Date Tue, 03 Apr 2018 00:32:00 GMT


James Taylor commented on PHOENIX-4616:

Is the derived-table the only exception and if so can we test for that too in some way?

Alternatively, we could have three base classes for QueryPlan:
- BaseQueryPlan (or FinalQueryPlan or PhysicalQueryPlan or LeafQueryPlan?)
- JoinQueryPlan
- IntermediateQueryPlan  (or LogicalQueryPlan or NonLeafQueryPlan or CompositeQueryPlan )
Then just have an optimize method on QueryPlan with an implementation on these three classes.

If that's problematic, then go ahead and commit it as you have it.

> Move join query optimization out from QueryCompiler into QueryOptimizer
> -----------------------------------------------------------------------
>                 Key: PHOENIX-4616
>                 URL:
>             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:

This message was sent by Atlassian JIRA

View raw message