Re: Parallel Aggregate - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel Aggregate
Date
Msg-id CA+TgmoYLYFjCjQW7VQ8NZJ6-2KWKQheFp-XFFnnc_Rp+B_k+=g@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Aggregate  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: Parallel Aggregate
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: pglogical_output - a general purpose logical decoding output plugin
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types