The Distributed Merge Rules.

Nobody has claimed this yet.

What are the merge rules for distributed index?

My test seems to be based only on ID. Is it possible to use other merge rules? Or a specified field?

If duplicate ids occur, do you now leave data in the last index in the configuration?

```sql
create table shard0 (entity bigint, value text) type='rt' rt_mem_limit='12m';
create table shard1 (entity bigint, value text) type='rt' rt_mem_limit='12m';
create table shard type='distributed' local='shard0' local='shard1';
insert into shard0(id,entity,value) values(1, 100,'v1');
insert into shard1(id,entity,value) values(1, 100,'v2');
```
```sql
select * from shard;
```
use shard1 table data.
```text
+------+--------+-------+
| id | entity | value |
+------+--------+-------+
| 1 | 100 | v2 |
+------+--------+-------+
```

but
```sql
create table shard type='distributed' local='shard1' local='shard0';
```
use shard0 table data, because the configuration order has changed.
```text
+------+--------+-------+
| id | entity | value |
+------+--------+-------+
| 1 | 100 | v1 |
+------+--------+-------+
```

The configuration order determines the priority, right?

The issue provides a SQL reproduction using shard0, shard1, and the distributed shard. Start by checking the distributed-index documentation and relevant implementation for duplicate-ID merge behavior, then compare both configuration orders. Done means documenting whether configuration order determines priority and whether other merge rules or fields are supported.

Written by the indexing model from the issue text.