IIRC, it invokes tuples_equal for all cases unless we are using replica identity key or primary key to scan. But there seem some other cases where the tuples_equal looks unnecessary.
For example, if the table on subscriber don't have a PK or RI key but have a not-null, non-deferrable, unique key. And if the apply worker choose this index to do the scan, it seems we can skip the tuples_equal as well.
Yeah, that's right. I also spotted this earlier, see # Testcase start: Unique index
that is not primary key or replica identity
I'm thinking that we should not create any code complexity for this case, at least with
this patch. I have a few small follow-up ideas, like this one, or allow non-btree indexes etc.
but I'd rather not get those optional improvements to this patch, if that makes sense.
