Re: A reloption for partitioned tables - parallel_workers
От | Laurenz Albe |
---|---|
Тема | Re: A reloption for partitioned tables - parallel_workers |
Дата | |
Msg-id | 802f29bd9515c6852166f99dfd8aad32c0040edc.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: A reloption for partitioned tables - parallel_workers (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: A reloption for partitioned tables - parallel_workers
|
Список | pgsql-hackers |
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. 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. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: