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: | Raw Message | Whole Thread | 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 |