[
https://issues.apache.org/jira/browse/PHOENIX-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2269:
--
Description: Drill has already modeled aggregation as a distributed,
multi-step process that includes an initial aggregation step followed by a
shuffle. Phoenix should have a physical operator that executes the initial
aggregation step on the server-side. On the Phoenix side, we may be able to use
our same AggregatePlan since we grab the underlying Scan from the QueryPlan as
part of the information passed to the DrillBit. As long as the TupleProjector
contains the correct KeyValueSchema to interpret the results coming back from
the Scan, we have everything we need. We just need to make sure that Drill uses
our physical operator. (was: This includes two sub-tasks:
1. Model server-side partial aggregate and client-side merge aggregate as
Phoenix physical operators.
2. Split Phoenix AggregatePlan into two parts accordingly.)
> Implement Drill-specific rule for first level server-side aggregation
> -
>
> Key: PHOENIX-2269
> URL: https://issues.apache.org/jira/browse/PHOENIX-2269
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Labels: calcite, drill
>
> Drill has already modeled aggregation as a distributed, multi-step process
> that includes an initial aggregation step followed by a shuffle. Phoenix
> should have a physical operator that executes the initial aggregation step on
> the server-side. On the Phoenix side, we may be able to use our same
> AggregatePlan since we grab the underlying Scan from the QueryPlan as part of
> the information passed to the DrillBit. As long as the TupleProjector
> contains the correct KeyValueSchema to interpret the results coming back from
> the Scan, we have everything we need. We just need to make sure that Drill
> uses our physical operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
