On Fri, Nov 18, 2022 at 10:31 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Fri, Nov 18, 2022 at 1:47 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Nov 18, 2022 at 8:01 AM Peter Smith <smithpb2...@gmail.com> wrote: > > > > > > 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. > > > > > > > > If we do that then how will the user be able to use streaming > > serialize mode (write to file for streaming transactions) as we have > > now? Because after we introduce parallelism for non-streaming > > transactions, the user would want parallel = on irrespective of the > > streaming mode. Also, users may wish to only parallelize large > > transactions because of additional overhead for non-streaming > > transactions for transaction dependency tracking, etc. So, the user > > may wish to have a separate knob for large transactions as the patch > > has now. > > One idea for that would be to make it enum. For example, setting > parallel = "streaming" works for that. >
Yeah, but then we will have two different parameters (parallel and streaming) to control streaming behavior. This will be confusing say when the user says parallel = 'streaming' and streaming = off, we need to probably disallow such settings but not sure if it would be any better than allowing parallelism for large xacts by streaming parameter. -- With Regards, Amit Kapila.