Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit fd48a86

Browse files
Doc: clarify the conditions of usable indexes for REPLICA IDENTITY FULL tables.
Commit 89e46da allowed REPLICA IDENTITY FULL tables to use an index on the subscriber during apply of update/delete. This commit clarifies in the documentation that the leftmost field of candidate indexes must be a column (not an expression) that references the published relation column. The source code comments are also updated accordingly. Reviewed-by: Peter Smith, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDJjffEvUFKXT27Q5U8-UU9JHv4rrJ9Ke8Zkc5UPWHLvA@mail.gmail.com Backpatch-through: 16
1 parent 0fef877 commit fd48a86

File tree

3 files changed

+13
-16
lines changed

3 files changed

+13
-16
lines changed

doc/src/sgml/logical-replication.sgml

+6-6
Original file line numberDiff line numberDiff line change
@@ -134,12 +134,12 @@
134134
to replica identity <literal>FULL</literal>, which means the entire row becomes
135135
the key. When replica identity <literal>FULL</literal> is specified,
136136
indexes can be used on the subscriber side for searching the rows. Candidate
137-
indexes must be btree, non-partial, and have at least one column reference
138-
(i.e. cannot consist of only expressions). These restrictions
139-
on the non-unique index properties adhere to some of the restrictions that
140-
are enforced for primary keys. If there are no such suitable indexes,
141-
the search on the subscriber side can be very inefficient, therefore
142-
replica identity <literal>FULL</literal> should only be used as a
137+
indexes must be btree, non-partial, and the leftmost index field must be a
138+
column (not an expression) that references the published table column. These
139+
restrictions on the non-unique index properties adhere to some of the
140+
restrictions that are enforced for primary keys. If there are no such
141+
suitable indexes, the search on the subscriber side can be very inefficient,
142+
therefore replica identity <literal>FULL</literal> should only be used as a
143143
fallback if no other solution is possible. If a replica identity other
144144
than <literal>FULL</literal> is set on the publisher side, a replica identity
145145
comprising the same or fewer columns must also be set on the subscriber

src/backend/executor/execReplication.c

+3-3
Original file line numberDiff line numberDiff line change
@@ -47,9 +47,9 @@ static bool tuples_equal(TupleTableSlot *slot1, TupleTableSlot *slot2,
4747
*
4848
* Returns how many columns to use for the index scan.
4949
*
50-
* This is not generic routine, it expects the idxrel to be a btree, non-partial
51-
* and have at least one column reference (i.e. cannot consist of only
52-
* expressions).
50+
* This is not generic routine, idxrel must be PK, RI, or an index that can be
51+
* used for REPLICA IDENTITY FULL table. See FindUsableIndexForReplicaIdentityFull()
52+
* for details.
5353
*
5454
* By definition, replication identity of a rel meets all limitations associated
5555
* with that. Note that any other index could also meet these limitations.

src/backend/replication/logical/relation.c

+4-7
Original file line numberDiff line numberDiff line change
@@ -779,9 +779,10 @@ RemoteRelContainsLeftMostColumnOnIdx(IndexInfo *indexInfo, AttrMap *attrmap)
779779

780780
/*
781781
* Returns the oid of an index that can be used by the apply worker to scan
782-
* the relation. The index must be btree, non-partial, and have at least
783-
* one column reference (i.e. cannot consist of only expressions). These
784-
* limitations help to keep the index scan similar to PK/RI index scans.
782+
* the relation. The index must be btree, non-partial, and the leftmost
783+
* field must be a column (not an expression) that references the remote
784+
* relation column. These limitations help to keep the index scan similar
785+
* to PK/RI index scans.
785786
*
786787
* Note that the limitations of index scans for replica identity full only
787788
* adheres to a subset of the limitations of PK/RI. For example, we support
@@ -796,10 +797,6 @@ RemoteRelContainsLeftMostColumnOnIdx(IndexInfo *indexInfo, AttrMap *attrmap)
796797
* none of the tuples satisfy the expression for the index scan, we fall-back
797798
* to sequential execution, which might not be a good idea in some cases.
798799
*
799-
* We also skip indexes if the remote relation does not contain the leftmost
800-
* column of the index. This is because in most such cases sequential scan is
801-
* favorable over index scan.
802-
*
803800
* We expect to call this function when REPLICA IDENTITY FULL is defined for
804801
* the remote relation.
805802
*

0 commit comments

Comments
 (0)