Re: Choosing parallel_degree
От | Robert Haas |
---|---|
Тема | Re: Choosing parallel_degree |
Дата | |
Msg-id | CA+TgmoYSsSL7AKQstOWskdXzzNJ9ezyG7v+vPrKG3bk5YChGKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Choosing parallel_degree (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Choosing parallel_degree
|
Список | pgsql-hackers |
On Mon, Mar 14, 2016 at 9:25 PM, David Rowley <david.rowley@2ndquadrant.com> wrote: > Over in [1] James mentioned about wanting more to be able to have more > influence over the partial path's parallel_degree decision. At risk > of a discussion on that hijacking the parallel aggregate thread, I > thought I'd start this for anyone who would want to discuss making > changes to that. > > I've attached a simple C program which shows the parallel_degree which > will be chosen at the moment. For now it's based on the size of the > base relation. Perhaps that will need to be rethought later, perhaps > based on costs. But I just don't think it's something for 9.6. I thought about this a bit more. There are a couple of easy things we could do here. The 1000-page threshold could be made into a GUC. We could add a per-table reloption for parallel-degree that would override the calculation. Neither of those things is very smart, but they'd probably both help some people. If someone is able to produce a patch for either or both of these things *quickly*, we could possibly try to squeeze it into 9.6 as a cleanup of work already done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: