MIME-Version: 1.0
References: <E1tsZjz-002Ctd-1G@gemulon.postgresql.org>
In-Reply-To: <E1tsZjz-002Ctd-1G@gemulon.postgresql.org>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 17 Mar 2025 12:05:22 -0400
Message-ID: 
 <CA+Tgmoa+GkGNZ86QmqyuOCHWaBkOEJAEPfghEQ1d8_+KudVknw@mail.gmail.com>
Subject: Re: pgsql: Avoid invalidating all RelationSyncCache entries on
 publication
To: Amit Kapila <akapila@postgresql.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoa%2BGkGNZ86QmqyuOCHWaBkOEJAEPfghEQ1d8_%2BKudVknw%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 13, 2025 at 12:00=E2=80=AFAM Amit Kapila <akapila@postgresql.or=
g> wrote:
> Avoid invalidating all RelationSyncCache entries on publication rename.
>
> On Publication rename, we need to only invalidate the RelationSyncCache
> entries corresponding to relations that are part of the publication being
> renamed.
>
> As part of this patch, we introduce a new invalidation message to
> invalidate the cache maintained by the logical decoding output plugin. We
> can't use existing relcache invalidation for this purpose, as that would
> unnecessarily cause relcache invalidations in other backends.

This seems like too much infrastructure for a niche optimization. If
there are plans to use this new invalidation message type to optimize
a bunch of other cases, then maybe it's worth it, but adding this just
to cover the presumably-rare case of ALTER PUBLICATION .. RENAME
doesn't seem worth it to me.

--=20
Robert Haas
EDB: http://www.enterprisedb.com