diff --git a/src/backend/replication/logical/relation.c b/src/backend/replication/logical/relation.c
index ba8655d608..62a8a9ea87 100644
--- a/src/backend/replication/logical/relation.c
+++ b/src/backend/replication/logical/relation.c
@@ -711,8 +711,6 @@ logicalrep_partition_open(LogicalRepRelMapEntry *root,
 	/* Set if the table's replica identity is enough to apply update/delete. */
 	logicalrep_rel_mark_updatable(entry);
 
-	entry->localrelvalid = true;
-
 	/* state and statelsn are left set to 0. */
 	MemoryContextSwitchTo(oldctx);
 
@@ -728,6 +726,8 @@ logicalrep_partition_open(LogicalRepRelMapEntry *root,
 	 */
 	entry->usableIndexOid = FindLogicalRepUsableIndex(partrel, remoterel);
 
+	entry->localrelvalid = true;
+
 	return entry;
 }
 
@@ -753,26 +753,29 @@ IsIndexOnlyOnExpression(IndexInfo *indexInfo)
 }
 
 /*
- * Returns the oid of an index that can be used via the apply worker. The index
- * should be btree, non-partial and have at least one column reference (i.e.
- * cannot consist of only expressions). The limitations arise from
- * RelationFindReplTupleByIndex(), which is designed to handle PK/RI.
+ * Returns the oid of an index that can be used by the apply worker to scan
+ * the relation. The index should be btree, non-partial, and have at least
+ * one column reference (i.e. cannot consist of only expressions). These
+ * limitations help to keep the index scan similar to PK/RI index scans.
  *
  * Note that the limitations of index scans for replica identity full only
- * adheres a subset of the limitations of PK/RI. For example, we support
- * columns that are not marked as [NOT NULL] or we are not interested in
- * [NOT DEFERRABLE] aspect of constraints here.
+ * adheres to a subset of the limitations of PK/RI. For example, we support
+ * columns that are marked as [NULL] or we are not interested in the [NOT
+ * DEFERRABLE] aspect of constraints here. It works for us because we always
+ * compare the tuples for non-PK/RI index scans. See
+ * RelationFindReplTupleByIndex().
  *
- * If no suitable index is found, returns InvalidOid.
+ * XXX: There are no fundamental problems for supporting non-btree indexes.
+ * We mostly need to relax the limitations in RelationFindReplTupleByIndex().
+ * For partial indexes, the required changes are likely to be larger. If
+ * none of the tuples satisfy the expression for the index scan, we should
+ * fall-back to sequential execution, which might not be a good idea in some
+ * cases.
  *
- * XXX: There are no fundamental problems for supporting non-btree indexes. We
- * should mostly relax the limitations in RelationFindReplTupleByIndex(). For
- * partial indexes, the required changes likely to be larger. If none of the
- * tuples satisfy the expression for the index scan, we should fall-back to
- * sequential execution, which might not be a good idea in some cases.
+ * We expect to call this function when REPLICA IDENTITY FULL is defined for
+ * the remote relation.
  *
- * Note that this is not a generic function, it expects REPLICA IDENTITY FULL
- * for the remote relation.
+ * If no suitable index is found, returns InvalidOid.
  */
 static Oid
 FindUsableIndexForReplicaIdentityFull(Relation localrel)
@@ -881,10 +884,6 @@ FindLogicalRepUsableIndex(Relation localrel, LogicalRepRelation *remoterel)
 		remoterel->replident == REPLICA_IDENTITY_FULL)
 	{
 		/*
-		 * If we had a primary key or relation identity with a unique index,
-		 * we would have already found and returned that oid. At this point,
-		 * the remote relation has replica identity full.
-		 *
 		 * We are looking for one more opportunity for using an index. If
 		 * there are any indexes defined on the local relation, try to pick a
 		 * suitable index.
@@ -892,6 +891,11 @@ FindLogicalRepUsableIndex(Relation localrel, LogicalRepRelation *remoterel)
 		 * The index selection safely assumes that all the columns are going
 		 * to be available for the index scan given that remote relation has
 		 * replica identity full.
+		 *
+		 * Note that we are not using the planner to find the cheapest method
+		 * to scan the relation as that would require us to either use lower
+		 * level planner functions which would be a maintenance burden in the
+		 * long run or use the full-fledged planner which could cause overhead.
 		 */
 		return FindUsableIndexForReplicaIdentityFull(localrel);
 	}