[
https://issues.apache.org/jira/browse/PHOENIX-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2197:
----------------------------------
Description:
The DML commands in Phoenix are compiled with an UpsertCompiler and
DeleteCompiler. The result compilation is a MutationPlan which may be executed
similar to a QueryPlan. In the case of UPSERT SELECT and DELETE, the
MutationPlan wraps a QueryPlan.
For the Phoenix-Calcite integration, we can produce the same MutationPlan for
each category of DML. Typically these MutationPlans are anonymous inner
classes, so they'll likely need to be broken up and put in their own top level
class.
There are typically two branches of code for each - when the command may be
executed purely on the server-side (an optimization to reduce data being
unnecessarily transferred from the server back to the client) versus on the
client-side. For UPSERT SELECT, we only execute a query on the server-side if
the following conditions are met:
- single table select
- autocommit is on
- the table being selected from matches the table being upserted into
- the table has no immutable indexes as these are maintained on the client-side.
- no post processing is required by the query:
- the query isn't doing aggregation
- the query doesn't have a LIMIT clause
- the query has no ORDER BY clause
- the query doesn't use sequences (since we require the rows to be upserted
in the same order as they are selected in this case).
We can likely collapse UPSERT SELECT and UPSERT VALUES as Calcite has a good
abstraction for a VALUES clause.
Much of the logic in UpsertCompiler is likely similar to the massaging done by
Calcite during compilation, so if we can adapt our MutationPlan generation to
Calcite objects, I think we'll be better off in the long run.
was:
The DML commands in Phoenix are compiled with an UpsertCompiler and
DeleteCompiler. The result compilation is a MutationPlan which may be executed
similar to a QueryPlan. In the case of UPSERT SELECT and DELETE, the
MutationPlan wraps a QueryPlan.
For the Phoenix-Calcite integration, we can produce the same MutationPlan for
each category of DML. Typically these MutationPlans are anonymous inner
classes, so they'll likely need to be broken up and put in their own top level
class.
There are typically two branches of code for each - when the command may be
executed purely on the server-side (an optimization to reduce data being
unnecessarily transferred from the server back to the client) versus on the
client-side. For UPSERT SELECT, we only execute a query on the server-side if
the following conditions are met:
- single table select
- autocommit is on
- the table being selected from matches the table being upserted into
- the table has no immutable indexes as these are maintained on the client-side.
- no post processing is required by the query:
- the query isn't doing aggregation
- the query doesn't have a LIMIT clause
- the query has no ORDER BY clause
- the query doesn't use sequences (since we require the rows to be upserted
in the same order as they are selected in this case).
We can likely collapse UPSERT SELECT and UPSERT VALUES as Calcite has a good
abstraction for a VALUES clause.
Much of the logic in UpsertCompiler is likely similar to the massaging done by
Calcite during compilation, so if we can adapt our MutationPlan generation to
Calcite objects, I think we'll be better off in the long run.
> Support DML in Phoenix/Calcite integration
> ------------------------------------------
>
> Key: PHOENIX-2197
> URL: https://issues.apache.org/jira/browse/PHOENIX-2197
> Project: Phoenix
> Issue Type: New Feature
> Reporter: James Taylor
>
> The DML commands in Phoenix are compiled with an UpsertCompiler and
> DeleteCompiler. The result compilation is a MutationPlan which may be
> executed similar to a QueryPlan. In the case of UPSERT SELECT and DELETE, the
> MutationPlan wraps a QueryPlan.
> For the Phoenix-Calcite integration, we can produce the same MutationPlan for
> each category of DML. Typically these MutationPlans are anonymous inner
> classes, so they'll likely need to be broken up and put in their own top
> level class.
> There are typically two branches of code for each - when the command may be
> executed purely on the server-side (an optimization to reduce data being
> unnecessarily transferred from the server back to the client) versus on the
> client-side. For UPSERT SELECT, we only execute a query on the server-side if
> the following conditions are met:
> - single table select
> - autocommit is on
> - the table being selected from matches the table being upserted into
> - the table has no immutable indexes as these are maintained on the
> client-side.
> - no post processing is required by the query:
> - the query isn't doing aggregation
> - the query doesn't have a LIMIT clause
> - the query has no ORDER BY clause
> - the query doesn't use sequences (since we require the rows to be
> upserted in the same order as they are selected in this case).
> We can likely collapse UPSERT SELECT and UPSERT VALUES as Calcite has a good
> abstraction for a VALUES clause.
> Much of the logic in UpsertCompiler is likely similar to the massaging done
> by Calcite during compilation, so if we can adapt our MutationPlan generation
> to Calcite objects, I think we'll be better off in the long run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
