phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4703) Provide an option to fully rebuild indexes asynchronously through SQL
Date Tue, 07 May 2019 00:20:00 GMT


Hudson commented on PHOENIX-4703:

FAILURE: Integrated in Jenkins build Phoenix-4.x-HBase-1.4 #135 (See [])
PHOENIX-4703 Make indextool changes to drop before rebuild (gjacoby: rev 4dabc18879a56cffed54edc20a5556ec071520ab)
* (add) phoenix-core/src/it/java/org/apache/phoenix/end2end/
* (edit) phoenix-core/src/main/java/org/apache/phoenix/mapreduce/index/

> Provide an option to fully rebuild indexes asynchronously through SQL
> ---------------------------------------------------------------------
>                 Key: PHOENIX-4703
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Vincent Poon
>            Assignee: Gokcen Iskender
>            Priority: Major
>             Fix For: 4.15.0, 5.1.0
>         Attachments: PHOENIX-4703-4.x.patch, PHOENIX-4703.patch
>          Time Spent: 5h
>  Remaining Estimate: 0h
> Currently if we run "ALTER INDEX ... REBUILD" , all the rows in the index are deleted
and the index is rebuilt synchronously.
> "ALTER INEX ... REBUILD ASYNC" seems to be used for the IndexTool's partial rebuild option,
> So it seems currently the only way to fully rebuild is the drop the index, and recreate
it.  This is burdensome as it requires have the schema DDL.
> We should have an option to fully rebuild asynchronously, that has the same semantics
as dropping and recreating the index.  A further advantage of this is we can maintain the
splits of the index table while dropping its data.  We are currently seeing issues where
rebuilding a large table via a MR job results in hotspotting due to all data regions writing
to the same index region at the start.

This message was sent by Atlassian JIRA

View raw message