Options to heal a fragmented stable row id

The stable row id feature introduces a row id index that fragments as updates occur. The size of this index grows linearly with the number of updates. Just from some rough benchmarking:

This is primarily a cold-start problem. The row id index generally has to be reloaded each time a new dataset version is loaded into memory and this can get quite slow as the index gets large.

However, the larger indexes are slightly slower to apply as well.

As an escape valve we could create a new task, like compaction, which reclusters the data in row id order. This would heal the row id index without changing the semantic meaning of the row ids (e.g. row 7 would still be row 7) but it would require a complete rewrite of the data (it's basically a table copy at this point).

Another escape valve could be to just reassign row ids. This would break the stable row guarantee (row 7 might now be row 400) but it would very fast.

Start by tracing the stable row id index and how it is reloaded for each dataset version, then compare the issue's two proposed escape valves: reclustering data in row id order or reassigning row ids. Done requires a decided approach that addresses index growth and cold-start cost while documenting whether stable row semantics are preserved.