James Taylor created PHOENIX-2197:
-------------------------------------
Summary: 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)
