1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-14 18:42:34 +03:00

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

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

View File

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

View File

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

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 * 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 * the relation. The index must be btree, non-partial, and the leftmost
* one column reference (i.e. cannot consist of only expressions). These * field must be a column (not an expression) that references the remote
* limitations help to keep the index scan similar to PK/RI index scans. * 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 * 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 * 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 * 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. * 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 * We expect to call this function when REPLICA IDENTITY FULL is defined for
* the remote relation. * the remote relation.
* *