Re: Parallel Aggregate
От | David Rowley |
---|---|
Тема | Re: Parallel Aggregate |
Дата | |
Msg-id | CAKJS1f_itLNeVB9uV4GYiBrRZxtpVVyqRSGjKgW+W3AsA1oH8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Aggregate (James Sewell <james.sewell@lisasoft.com>) |
Список | pgsql-hackers |
On 15 March 2016 at 11:24, James Sewell <james.sewell@lisasoft.com> wrote: > On Tuesday, 15 March 2016, Robert Haas <robertmhaas@gmail.com> wrote: >> >> > 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. >> :-( > > > Any chance of getting a GUC (say min_parallel_degree) added to allow setting > the initial value of parallel_degree, then changing the small relation check > to also pass if parallel_degree > 1? > > That way you could set min_parallel_degree on a query by query basis if you > are running aggregates which you know will take a lot of CPU. > > I suppose it wouldn't make much sense at all to set globally though, so it > could just confuse matters. I agree that it would be nice to have more influence on this decision, but let's start a new thread for that. I don't want this one getting bloated with debates on that. It's not code I'm planning on going anywhere near for this patch. I'll start a thread... -- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: