feat: support when_matched_delete in merge_insert

[jtuglu1]

Closes #2271

[codecov-commenter]

Codecov Report

❌ Patch coverage is 86.30807% with 56 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ance/src/dataset/write/merge_insert/exec/delete.rs	78.50%	33 Missing and 13 partials ⚠️
rust/lance/src/dataset/write/merge_insert.rs	94.20%	8 Missing ⚠️
...lance/src/dataset/write/merge_insert/exec/write.rs	90.90%	0 Missing and 1 partial ⚠️
...nce/src/dataset/write/merge_insert/logical_plan.rs	92.85%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[jtuglu1]

@wjones127 I plan to push some changes to bump the coverage a bit. Lack of coverage is from explain/analyze plan methods. Something I think would be a good idea to future-proof this file is starting to standardize how these various combinations of configs should be unit tested together. We can always attempt to test all relevant combinations with targeted tests, but not sure how scalable that is. Maybe there's a better approach with parameterized tests, etc.?

[wjones127]

Maybe there's a better approach with parameterized tests, etc.?

There's probably a better parametrized test. I'm working on adding a larger test suite, which can cover more write cases.

[jackye1995]

mostly looks good to me, some minor comments

[jtuglu1]

@wjones127 @jackye1995 thoughts here?

[jackye1995]

@jtuglu1 I thought about this a bit more, and also saw Will's old comment (sorry totally missed that previously) I think what Will suggested makes sense, I pushed a commit to add DeleteOnlyMergeInsertExec with some additional refactoring, let me know if this looks good to you

[jtuglu1]

Yeah I considered this (and Will's comment), but I didn't really like the idea of adding physical plans for every single type of enum (.*MergeInsertExec). It seemed easier (to me) to handle things all in the same codepath (the projection optimizations, etc.). I haven't really looked through your changes here yet, but are there any performance benefits as compared to the current implementation?

Edit: looks like this is skipping write step which is I guess some time saved.

[jackye1995]

Edit: looks like this is skipping write step which is I guess some time saved.

yes that's the main goal

[jackye1995]

thanks for working through this!