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  (James Sewell <james.sewell@lisasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pglogical_output - a general purpose logical decoding output plugin
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types