Hi Hou zj, all > > 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. Thanks, Onder KALACI
