Re: Parallel Aggregate - Mailing list pgsql-hackers

From James Sewell
Subject Re: Parallel Aggregate
Date
Msg-id CANkGpBtUvzpdvF2=_iQ64UjmVrPYcS6d4i9-wepbUsq1sq+AWw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Aggregate  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel Aggregate
Re: Parallel Aggregate
List pgsql-hackers
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.

Cheers,

 


The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix for OpenSSL error queue bug
Next
From: Robert Haas
Date:
Subject: Re: Parallel Aggregate