[
https://issues.apache.org/jira/browse/PHOENIX-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363598#comment-16363598
]
James Taylor commented on PHOENIX-4344:
---------------------------------------
Phoenix will do a point delete (i.e. the Phoenix client will issue an HBase
Delete with the full row key) because it thinks it has values for all the
columns that make up the primary key of the base table. In this case, it
doesn't need to issue a scan at all. The problem is, Phoenix doesn't know that
there are derived views that have extended the PK.
One solution would be to have a declaration on the base table that it would
never be used to upsert data directly. Something like declaring it ABSTRACT. In
that case, if you deleted from it, Phoenix could know to issue a scan instead
of trying to optimize it as a point delete.
Another solution would be to issue the delete statement against the view in the
MR job. Since the view has extended the PK, Phoenix wouldn't issue a point
delete, but would issue a scan. That might not be feasible, though, as it'd be
tricky to know all the views.
> MapReduce Delete Support
> ------------------------
>
> Key: PHOENIX-4344
> URL: https://issues.apache.org/jira/browse/PHOENIX-4344
> Project: Phoenix
> Issue Type: New Feature
> Affects Versions: 4.12.0
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
>
> Phoenix already has the ability to use MapReduce for asynchronous handling of
> long-running SELECTs. It would be really useful to have this capability for
> long-running DELETEs, particularly of tables with indexes where using HBase's
> own MapReduce integration would be prohibitively complicated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
