| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
| Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Parallel Aggregate |
| Date: | 2015-12-21 23:38:15 |
| Message-ID: | CAKJS1f9WC+9REW3kRAt0BAZ8c9JvtyUeovzOPfYSjo7A0nxdSA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 22 December 2015 at 04:16, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> wrote:
> Shouldn’t parallel aggregate come into play regardless of scan selectivity?
>
I'd say that the costing should take into account the estimated number of
groups.
The more tuples that make it into each group, the more attractive parallel
grouping should seem. In the extreme case if there's 1 tuple per group,
then it's not going to be of much use to use parallel agg, this would be
similar to a scan with 100% selectivity. So perhaps the costings for it can
be modeled around a the parallel scan costing, but using the estimated
groups instead of the estimated tuples.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2015-12-22 00:53:08 | Re: Combining Aggregates |
| Previous Message | Haribabu Kommi | 2015-12-21 23:35:18 | Re: Parallel Aggregate |