Shallow clone has much worse random take() latency than source dataset for heavy columns under concurrency

Hi, I am seeing a significant read-performance gap between a Lance dataset and a shallow clone of the same dataset for random row take() workloads.

The regression does not appear to be a general shallow-clone penalty:

• light columns behave similarly between source and clone
• heavy columns (e.g. high res images) show worse latency on the clone, especially p99 under concurrency
• the effect is much more visible under concurrency (processes=8)

Representative results

Full workload on heavy columns, 8 processes, Lance Python package 7.0.0

• source: p50 181 ms, p99 471 ms
• clone: p50 209 ms, p99 5347 ms

Expected behavior

A shallow clone should have roughly similar read performance to the source dataset for the same data and version.

Minimal reproduction outline

1. Create a local Lance dataset with:
   • small metadata/light scalar columns
   • several heavy binary columns
   • several heavy list columns
2. Build the dataset using multiple append writes
3. Tag the final version
4. Create a shallow clone from that tag
5. Benchmark random take() on:
   • light columns only
   • heavy columns only
   • all columns
6. Compare source vs clone using the same sampled row indices and concurrent workers

Start by reproducing the reported benchmark with the Lance Python package: build a dataset with light and heavy columns, create a tagged shallow clone, and compare random take() latency using the same row indices with processes=8. Compare light, heavy, and all-column workloads; done means the clone no longer shows the reported heavy-column concurrency regression against the source.