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