| From: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
|---|---|
| To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> | 
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, James Sewell <james(dot)sewell(at)lisasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Parallel Aggregate | 
| Date: | 2016-03-14 20:54:46 | 
| Message-ID: | CA+TgmoYLYFjCjQW7VQ8NZJ6-2KWKQheFp-XFFnnc_Rp+B_k+=g@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, Mar 14, 2016 at 3:56 PM, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> wrote:
> On Sun, Mar 13, 2016 at 7:31 PM, David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>> On 14 March 2016 at 14:52, James Sewell <james(dot)sewell(at)lisasoft(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2016-03-14 21:38:59 | Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types | 
| Previous Message | Andres Freund | 2016-03-14 20:48:09 | Re: pglogical_output - a general purpose logical decoding output plugin |