Hi all, Thanks for the feedback!
I agree that it won't be a very convenient option for the user but how > about along with asking for an index from the user (when the user > didn't provide an index), we also allow to make use of any unique > index over a subset of the transmitted columns, Tbh, I cannot follow why you would use REPLICA IDENTITY FULL if you can already create a unique index? Aren't you supposed to use REPLICA IDENTITY .. USING INDEX in that case (if not simply pkey)? That seems like a potential expansion of this patch, but I don't consider it as essential. Given it is hard to get even small commits in, I'd rather wait to see what you think before doing such a change. > and if there's more > than one candidate index pick any one. Additionally, we can allow > disabling the use of an index scan for this particular case. If we are > too worried about API change for allowing users to specify the index > then we can do that later or as a separate patch. > > On v23, I dropped the planner support for picking the index. Instead, it simply iterates over the indexes and picks the first one that is suitable. I'm currently thinking on how to enable users to override this decision. One option I'm leaning towards is to add a syntax like the following: *ALTER SUBSCRIPTION .. ALTER TABLE ... SET INDEX ...* Though, that should probably be a seperate patch. I'm going to work on that, but still wanted to share v23 given picking the index sounds complementary, not strictly required at this point. Thanks, Onder
v23_0001_use_index_on_subs_when_pub_rep_ident_full.patch
Description: Binary data
