[jira] [Updated] (PHOENIX-2197) Support DML in Phoenix/Calcite integration

["James Taylor (JIRA)" <ji...@apache.org>]

     [ 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)