[
https://issues.apache.org/jira/browse/PHOENIX-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709940#comment-14709940
]
James Taylor commented on PHOENIX-2197:
---------------------------------------
Index maintenance is handled differently for DELETE versus UPSERT. For UPSERT,
if we can produce the same MutationPlan, we'll be fine. In the case of mutable
and local indexes, these get maintained on the server-side with the
MutationState class taking care of sending the server the state it needs to
maintain indexes. For immutable indexes, the incremental index maintenance is
also handled in MutationState by producing and sending mutations for both the
data tables and any index tables.
For DELETE, the logic for mutable and local indexes is also incapsulated in
both the MutationPlan and MutationState. In general, it's simply a matter of
sending along the necessary metadata with the batched mutations (or making a
separate RPC before the batched mutation to send this information over).
For immutable indexes, the index maintenance for DELETE is handled during
compilation, so this will likely need to be reworked some. The implementation
essentially generates the equivalent DELETE statement against each immutable
index table. All of these DELETE statements are run in turn when a delete
occurs against a table with one or more indexes for an immutable table. Also,
there's some validation logic that is done up front to ensure that the DELETE
statement is allowed when the immutable table has indexes. It's here that we
detect cases in which we *can't* maintain the index and then disallow the
delete from running. This can occur if the original DELETE statement is
filtering on information that's not available in the index (see DeleteCompiler
for code comments to this affect).
> 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)
