On Tue, Feb 16, 2021 at 11:02 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> On Tue, 2021-02-16 at 16:29 +0900, Amit Langote wrote:
> > > I am +1 on allowing to override the degree of parallelism on a parallel
> > > append. If "parallel_workers" on the partitioned table is an option for
> > > that, it might be a simple solution. On the other hand, perhaps it would
> > > be less confusing to have a different storage parameter name rather than
> > > having "parallel_workers" do double duty.
> > > Also, since there is a design rule that storage parameters can only be used
> > > on partitions, we would have to change that - is that a problem for anybody?
> >
> > I am not aware of a rule that suggests that parallel_workers is always
> > interpreted using storage-level considerations. If that is indeed a
> > popular interpretation at this point, then yes, we should be open to
> > considering a new name for the parameter that this patch wants to add.
>
> Well, https://www.postgresql.org/docs/current/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
> says:
>
> "Specifying these parameters for partitioned tables is not supported,
> but you may specify them for individual leaf partitions."
>
> If we re-purpose "parallel_workers" like this, we'd have to change this.
Right, as I mentioned in my reply, the patch will need to update the
documentation.
> Then for a normal table, "parallel_workers" would mean how many workers
> work on a parallel table scan. For a partitioned table, it determines
> how many workers work on a parallel append.
>
> Perhaps that is similar enough that it is not confusing.
I tend to agree with that.
--
Amit Langote
EDB: http://www.enterprisedb.com
