database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-25 21:42:33 +03:00
Code

Doc: clarify the conditions of usable indexes for REPLICA IDENTITY FULL tables.

Browse Source 
Commit 89e46da5e 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
This commit is contained in:
Masahiko Sawada 2023-07-13 15:03:17 +09:00
parent 0fef877538
commit fd48a86c62
3 changed files with 13 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/sgml/logical-replication.sgml
View File

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

6
src/backend/executor/execReplication.c
View File

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

11
src/backend/replication/logical/relation.c
View File

@ -779,9 +779,10 @@ RemoteRelContainsLeftMostColumnOnIdx(IndexInfo *indexInfo, AttrMap *attrmap)
/*
* Returns the oid of an index that can be used by the apply worker to scan
* the relation. The index must 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.
* the relation. The index must be btree, non-partial, and the leftmost
* field must be a column (not an expression) that references the remote
* relation column. 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 to a subset of the limitations of PK/RI. For example, we support
@ -796,10 +797,6 @@ RemoteRelContainsLeftMostColumnOnIdx(IndexInfo *indexInfo, AttrMap *attrmap)
* none of the tuples satisfy the expression for the index scan, we fall-back
* to sequential execution, which might not be a good idea in some cases.
*
* We also skip indexes if the remote relation does not contain the leftmost
* column of the index. This is because in most such cases sequential scan is
* favorable over index scan.
*
* We expect to call this function when REPLICA IDENTITY FULL is defined for
* the remote relation.
*