Re: Parallel Aggregate
От | Robert Haas |
---|---|
Тема | Re: Parallel Aggregate |
Дата | |
Msg-id | CA+TgmoYLYFjCjQW7VQ8NZJ6-2KWKQheFp-XFFnnc_Rp+B_k+=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Aggregate (Paul Ramsey <pramsey@cleverelephant.ca>) |
Ответы |
Re: Parallel Aggregate
|
Список | pgsql-hackers |
On Mon, Mar 14, 2016 at 3:56 PM, Paul Ramsey <pramsey@cleverelephant.ca> wrote: > On Sun, Mar 13, 2016 at 7:31 PM, David Rowley > <david.rowley@2ndquadrant.com> wrote: >> On 14 March 2016 at 14:52, James Sewell <james.sewell@lisasoft.com> wrote: >>> One question - how is the upper limit of workers chosen? >> >> See create_parallel_paths() in allpaths.c. Basically the bigger the >> relation (in pages) the more workers will be allocated, up until >> max_parallel_degree. > > Does the cost of the aggregate function come into this calculation at > all? In PostGIS land, much smaller numbers of rows can generate loads > that would be effective to parallelize (worker time much >> than > startup cost). Unfortunately, no - only the table size. This is a problem, and needs to be fixed. However, it's probably not going to get fixed for 9.6. :-( -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: