Thread

1. [PATCH] Use direct hash lookup in logicalrep_partmap_invalidate_cb()

   DaeMyung Kang <charsyam@gmail.com> — 2026-04-17T17:44:50Z

   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(-)
   
   

2. Re: [PATCH] Use direct hash lookup in logicalrep_partmap_invalidate_cb()

   Michael Paquier <michael@paquier.xyz> — 2026-04-17T21:35:54Z

   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