On Fri, Nov 18, 2022 at 11:36 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > ... > --- > The streaming parameter has the new value "parallel" for "streaming" > option to enable the parallel apply. It fits so far but I think the > parallel apply feature doesn't necessarily need to be tied up with > streaming replication. For example, we might want to support parallel > apply also for non-streaming transactions in the future. It might be > better to have another option, say "parallel", to control parallel > apply behavior. The "parallel" option can be a boolean option and > setting parallel = on requires streaming = on. >
FWIW, I tend to agree with this idea but for a different reason. In this patch, the 'streaming' parameter had become a kind of hybrid boolean/enum. AFAIK there are no other parameters anywhere that use a hybrid pattern like this so I was thinking it may be better not to be different. But I didn't think that parallel_apply=on should *require* streaming=on. It might be better for parallel_apply=on is just the *default*, but it simply achieves nothing unless streaming=on too. That way users would not need to change anything at all to get the benefits of parallel streaming. > Another variant is to have a new subscription parameter for example > "parallel_workers" parameter that specifies the number of parallel > workers. That way, users can specify the number of parallel workers > per subscription. > ------ Kind Regards, Peter Smith. Fujitsu Australia.
