On Fri, Nov 18, 2022 at 11:36 AM Masahiko Sawada <sawada.mshk@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.