RE: [PATCH] Improving index selection for logical replication apply with replica identity full - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: [PATCH] Improving index selection for logical replication apply with replica identity full
Date
Msg-id TYRPR01MB12156CDC14DB15747719D38F9F5EF2@TYRPR01MB12156.jpnprd01.prod.outlook.com
Whole thread
In response to Re: [PATCH] Improving index selection for logical replication apply with replica identity full  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: [PATCH] Improving index selection for logical replication apply with replica identity full
List pgsql-hackers
Dear Bharath, Ethan,

> Do we know the cost of invoking the planner for index selection on the
> subscriber? AFAICS, the selection happens on the first apply or
> whenever the relcache entry gets invalidated - so it's infrequent [1].
> If that's the case, why not invoke the planner to make a
> better-informed decision? It would account for bloat, size,
> selectivity etc. I think it would be worth measuring the performance
> impact before proceeding with the just unique vs. non-unique approach.

Personally I'm still cautious to call planner code because of the maintenance cost.
I'm not sure it's helpful to extend codes only for the REPLICA IDENTITY FULL case.
But I see your point a bit, no one may not have compared these execution costs.

Regarding the code, it looked basically good, but one concern is that the
selection could be slightly worse if several indexes are defined; it needs to
iterate all the index entries in any cases. Can you prove the performance is
acceptable?

Best regards,
Hayato Kuroda
FUJITSU LIMITED




pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: psql: Fix CREATE SCHEMA scanning of nested routine bodies
Next
From: Dean Rasheed
Date:
Subject: Re: Allow ON CONFLICT DO UPDATE to return EXCLUDED values