database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Allow the use of a hash index on the subscriber during replication.

Browse Source 
Commit 89e46da5e5 allowed using BTREE indexes that are neither
PRIMARY KEY nor REPLICA IDENTITY on the subscriber during apply of
update/delete. This patch extends that functionality to also allow HASH
indexes.

We explored supporting other index access methods as well but they don't
have a fixed strategy for equality operation which is required by the
current infrastructure in logical replication to scan the indexes.

Author: Kuroda Hayato
Reviewed-by: Peter Smith, Onder Kalaci, Amit Kapila
Discussion: https://postgr.es/m/TYAPR01MB58669D7414E59664E17A5827F522A@TYAPR01MB5866.jpnprd01.prod.outlook.com
This commit is contained in:
Amit Kapila
2023-07-14 08:21:54 +05:30
parent a5ea825f95
commit edca342434
7 changed files with 186 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -134,9 +134,9 @@
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 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
indexes must be btree or hash, 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