Обсуждение: [PATCH] Use direct hash lookup in logicalrep_partmap_invalidate_cb()

LogicalRepPartMap is keyed by the partition's OID, which is assigned
to entry->relmapentry.localreloid when the entry is populated in
logicalrep_partition_open().  The invalidation callback therefore
does not need to iterate over every entry to find the one matching
the invalidated relation OID; a single hash_search(HASH_FIND) on
reloid suffices.

This replaces an O(N) hash_seq_search loop with an O(1) lookup and
removes the longstanding "TODO, use inverse lookup hashtable?"
comment.  An Assert in logicalrep_partition_open() documents the
partOid == entry->relmapentry.localreloid invariant that the new
path relies on.
---

Tested on an --enable-cassert build: the full src/test/subscription
TAP suite (39 files, 579 tests) passes, including 013_partition.pl
which exercises the partmap invalidation path via ADD COLUMN on a
partitioned root (cascades a relcache inval to every leaf partition).

 src/backend/replication/logical/relation.c | 23 +++++++++-------------
 1 file changed, 9 insertions(+), 14 deletions(-)

On Sat, Apr 18, 2026 at 02:44:50AM +0900, DaeMyung Kang wrote:
> LogicalRepPartMap is keyed by the partition's OID, which is assigned
> to entry->relmapentry.localreloid when the entry is populated in
> logicalrep_partition_open().  The invalidation callback therefore
> does not need to iterate over every entry to find the one matching
> the invalidated relation OID; a single hash_search(HASH_FIND) on
> reloid suffices.

At this stage of the release cycle (aka feature freeze is in effect as
of v19), I'd recommend that you add this patch to the next commit
fest, so as this could be considered for v20, whose development should
begin next July.  See [1].

[1]: https://commitfest.postgresql.org/59/
--
Michael