Hi Pooja

lets understand DV first -  This avoid rewriting entire files by marking rows as deleted/updated via a bitmap (the deletion vector), which should, in theory, be faster for small updates.

but DV introduces new overhead:

1) Writing and updating the DV metadata, and ensuring atomicity, adds I/O cost.

2) When DVs are present, Delta must read the original file and apply the DV mask at read time, which can slow down both the merge and subsequent reads.

3) additiional metadata handling using transaction logs. so we can think how dv involves updating parquet file footer, writing/updating dv file and also updating delta/transaction logs.

so my take is : Without partitioning, more data may need to be scanned and more DVs created, increasing overhead. Unless there is a real need of it for complex concurrency locking to avoid concurrent failure. Also. might be useful for large files with small updates but partitioned tables where rewriting would be expensive.

Always choose right strategy suited your workload.