# EXPLAIN REBALANCE PARTITIONS

The `EXPLAIN REBALANCE PARTITIONS` command returns the set of steps that `REBALANCE PARTITIONS` would run.

## Syntax

```sql
EXPLAIN REBALANCE PARTITIONS ON db_name

```

## Remarks

* `db_name` - name of a SingleStore database.
* [Node Requirements for SingleStore Commands](https://docs.singlestore.com/db/v9.0/reference/sql-reference/cluster-management-commands.md)
* See [MV\_REBALANCE\_STATUS](https://docs.singlestore.com/db/v9.0/reference/information-schema-reference/segment-column-and-merge-status/mv-rebalance-status.md) for the column definitions in the result set.

The *Ordinal* is the target partition’s ordinal, and the *Target\_Host* and *Target\_Port* correspond to the destination leaf. Any two operations in the same *Phase* can be run in parallel and phases are run in order. For example, the aggregator can run `COPY PARTITION` on partitions `test:1` and `test:3` in parallel. The exact meaning of what each phase means is arbitrary and depends on the particular rebalance operation.

## Estimated\_Time\_Remaining\_Ms

The `Estimated_Time_Remaining_Ms` column contains an estimate (in milliseconds) for each low-level command as follows:

* **Command is running**

  * The estimate is the remaining time for the command to complete.
  * For a running `COPY PARTITION` operation, the engine obtains the remaining-time estimate from the `ESTIMATED_CATCHUP_TIME_S` column in the [MV\_REPLICATION\_STATUS](https://docs.singlestore.com/db/v9.0/reference/information-schema-reference/replication-management/mv-replication-status.md) information schema view and converts it to milliseconds. For a running `PROMOTE` operation, the engine uses the larger of the catch-up estimate and the replay estimate. If the live estimates are not available, the value is `NULL`.
* **Command has not started**

  * The estimate is the expected runtime of the command.
  * For commands that have not started, `EXPLAIN REBALANCE`, and other action types (such as `DROP PARTITION`), SingleStore uses a per-database, per-action-type exponential moving average of previous completed runtimes. The latest measurement has a weight of 0.1, and the stored average has a weight of 0.9.

The estimate is based on historical runs for the same database and action type, and its accuracy depends on how well the previous runs reflect current conditions. It is not a confidence interval and does not automatically account for changes in data volume between infrequent rebalance operations.

## Example

```sql
EXPLAIN REBALANCE PARTITIONS ON memsql_demo;

```

```output

+-----------------------------+---------+-------------+-------------+-------+-----------------------------+
| Action                      | Ordinal | Target_Host | Target_Port | Phase | Estimated_Time_Remaining_Ms |
+-----------------------------+---------+-------------+-------------+-------+-----------------------------+
| COPY PARTITION              | 13      | 127.0.0.1   | 10002       | 3     | 7821                        |
| COPY PARTITION              | 2       | 127.0.0.1   | 10003       | 4     | 7821                        |
| COPY PARTITION              | 2       | 127.0.0.1   | 10004       | 4     | 7821                        |
| PROMOTE PARTITION WITH DROP | 2       | 127.0.0.1   | 10003       | 5     | 1351                        |
| DROP PARTITION              | 2       | 127.0.0.1   | 10002       | 6     | 1002                        |
| DROP PARTITION              | 13      | 127.0.0.1   | 10004       | 6     | 1002                        |
+-----------------------------+---------+-------------+-------------+-------+-----------------------------+
```

## Understanding the Rebalance Actions

Each action occurs on a single partition.

| Action                                    | Definition                                                                                                                                                                                                                                                                                                                 |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `COPY PARTITION`                          | Copies a partition and sets upreplication (Ensures redundancy in a cluster. There are two types of replication: high availability - replicating partitions between the leaf nodes and cluster replication - replicating partitions between clusters.)to keep the copy in sync.                                             |
| `PROMOTE PARTITION [WITH {DROP,REPOINT}]` | Promotes a replica partition into a master partition. The`WITH DROP`clause drops the previous master partition. The`WITH REPOINT`clause converts the previous master partition into a replica partition. There is no default, rebalance chooses one or the other based on the path to get to a balanced set of partitions. |
| `DROP PARTITION`                          | Drops a partition.                                                                                                                                                                                                                                                                                                         |

***

Modified at: October 16, 2026

Source: [/db/v9.0/reference/sql-reference/cluster-management-commands/explain-rebalance-partitions/](https://docs.singlestore.com/db/v9.0/reference/sql-reference/cluster-management-commands/explain-rebalance-partitions/)

(An index of the documentation is available at /llms.txt)