phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-2197) Support DML in Phoenix/Calcite integration
Date Mon, 24 Aug 2015 03:17:45 GMT

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

Mime
View raw message