On Tue, Feb 21, 2023 at 7:55 PM Önder Kalacı <onderkal...@gmail.com> wrote: > >> >> I think this overhead seems to be mostly due to the need to perform >> tuples_equal multiple times for duplicate values. I don't know if >> there is any simple way to avoid this without using the planner stuff >> as was used in the previous approach. So, this brings us to the >> question of whether just providing a way to disable/enable the use of >> index scan for such cases is sufficient or if we need any other way. >> >> Tom, Andres, or others, do you have any suggestions on how to move >> forward with this patch? >> > > Thanks for the feedback and testing. Due to personal circumstances, > I could not reply the thread in the last 2 weeks, but I'll be more active > going forward. > > I also agree that we should have a way to control the behavior. > > I created another patch (v24_0001_optionally_disable_index.patch) which can > be applied > on top of v23_0001_use_index_on_subs_when_pub_rep_ident_full.patch. > > The new patch adds a new subscription_parameter for both CREATE and ALTER > subscription > named: enable_index_scan. The setting is valid only when REPLICA IDENTITY is > full. > > What do you think about such a patch to control the behavior? It does not > give a per-relation > level of control, but still useful for many cases. >
Wouldn't a table-level option like 'apply_index_scan' be better than a subscription-level option with a default value as false? Anyway, the bigger point is that we don't see a better way to proceed here than to introduce some option to control this behavior. I see this as a way to provide this feature for users but I would prefer to proceed with this if we can get some more buy-in from senior community members (at least one more committer) and some user(s) if possible. So, I once again request others to chime in and share their opinion. -- With Regards, Amit Kapila.