From: Amit Kapila <amit.kapil...@gmail.com> > I think it would be good if the parallelism works by default when > required but I guess if we want to use something on these lines then > we can always check if the parallel_workers option is non-zero for a > relation (with RelationGetParallelWorkers). So users can always say > Alter Table <tbl_name> Set (parallel_workers = 0) if they don't want > to enable write parallelism for tbl and if someone is bothered that > this might impact Selects as well because the same option is used to > compute the number of workers for it then we can invent a second > option parallel_dml_workers or something like that.
Yes, if we have to require some specification to enable parallel DML, I agree that parallel query and parall DML can be separately enabled. With that said, I'm not sure if the user, and PG developers, want to allow specifying degree of parallelism for DML. > > As an aside, (1) and (2) has a potential problem with memory consumption. > > > > I can see the memory consumption argument for (2) because we might end > up generating parallel paths (partial paths) for reading the table but > don't see how it applies to (1)? I assumed that we would still open all partitions for parallel safety check in (1) and (2). In (1), parallel safety check is done only when parallel DML is explicitly enabled by the user. Just opening partitions keeps CacheMemoryContext bloated even after they are closed. Regards Takayuki Tsunakawa
