Upsert with 1M rows extremely slow due to `create_match_filter` and `txn.delete()` performance

Inizia dai punti di ingresso create_match_filter e txn.delete() descritti nel report, quindi riproduci il benchmark di upsert da 1M di righe a partire dalle tempistiche fornite. Esamina le issue correlate #2159, #2138 e #2943 per il contesto esistente. Il lavoro è completato quando è disponibile un miglioramento misurato oppure un modo documentato e supportato per evitare il costo riportato dell’eliminazione dell’intera tabella.

Apache Iceberg version

0.11.0

Please describe the bug 🐞

CC @goutamvenkat-anyscale @koenvo @Fokko

Hello! We are implementing distributed writes from Ray Data to Iceberg. As part of upserts, we:

1. Write data files in parallel across Ray workers (each worker writes its share of Parquet files directly to storage and returns DataFile metadata + the upsert key columns back to the driver)
2. On the driver, concatenate all upsert keys collected from workers, call create_match_filter to build a delete predicate, then call txn.delete() followed by an append to commit

Upserting 1M rows (383 MiB) into an Iceberg table takes ~17.5 minutes, almost entirely in the delete step:

create_match_filter (1M keys → In filter):   10.26s
txn.delete():                              1054.35s
append + commit:                              1.14s
─────────────────────────────────────────────────────
Total upsert commit:                       1065.75s

PyIceberg version 0.11.0

This matches what's reported in #2159 and #2138.

The bottlenecks are:

1. create_match_filter — constructs a Python BooleanExpression node per row, which is expensive at 1M+ keys
2. txn.delete() — evaluates the resulting giant In expression against the table's data files with no partition pruning, effectively doing a full table scan

We have a few questions:

1. Merge-on-read upserts — is this on the roadmap, and if so, roughly when? MoR would let us avoid the expensive delete + rewrite cycle entirely for large upserts.
2. Optimizing create_match_filter or txn.delete() — is there a recommended way to speed these up today? For example, batching the In filter, or passing a partition-level hint to constrain the file scan?
3. Partition-aware deletes — if the upsert key columns overlap with partition columns, is there a supported way to restrict txn.delete() to only the relevant partitions, rather than scanning the full table?

Related

• #2159 — Upserting large table extremely slow
• #2138 — Upsertion memory usage grows exponentially as table size grows
• #2943 — Optimize upsert performance for large datasets

Willingness to contribute

• I can contribute a fix for this bug independently
• I would be willing to contribute a fix for this bug with guidance from the Iceberg community
• I cannot contribute a fix for this bug at this time