Re: [PATCH] Improving index selection for logical replication apply with replica identity full

Hi,

On Tue, Jun 23, 2026 at 2:09 PM Ethan Mertz <ethan(dot)mertz(at)gmail(dot)com> wrote:
>
> > It might be worth factoring in the index size when more than one index
> > is usable unless others think otherwise. Since the replica identity
> > index is only re-picked on relcache invalidation, the choice could go
> > stale as bloat grows, so the apply worker might need to re-check the
> > replica identity index choice periodically.
>
> I partially spoke on this point earlier in my message, but my opinion is
> that either apply keep the heuristic simplistic, or apply should go into full
> query planning. In addition, adding relation size to the heuristic would make
> the behavior both dynamically but also less predictable. For users
> this might be difficult to understand.

I want to make sure we don't regress in the case where the unique
index has more bloat than the non-unique index. I experimented with a
small dataset where the unique index grew to 4.5 GB due to bloat and
observed that the patched was about 20% slower (a couple of seconds at
this scale, but in production with larger tables, more concurrent
activity, more bloat and limited memory, I would expect the gap to be
wider). Would you be able to provide some additional data points on
this before we proceed further? That would help confirm the heuristic
holds up across different bloat conditions.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com