On Thu, Mar 17, 2016 at 2:13 PM, James Sewell <james.sewell@lisasoft.com> wrote:
>
> Hi again,
>
> This is probably me missing something, but is there a reason parallel aggregate doesn't seem to ever create append
nodescontaining Index scans?
>
> SET random_page_cost TO 0.2;
> SET max_parallel_degree TO 8;
>
> postgres=# explain SELECT sum(count_i) FROM base GROUP BY view_time_day;
> QUERY PLAN
> -------------------------------------------------------------------------------------------------
> Finalize GroupAggregate (cost=310596.32..310598.03 rows=31 width=16)
> Group Key: view_time_day
> -> Sort (cost=310596.32..310596.79 rows=186 width=16)
> Sort Key: view_time_day
> -> Gather (cost=310589.00..310589.31 rows=186 width=16)
> Number of Workers: 5
> -> Partial HashAggregate (cost=310589.00..310589.31 rows=31 width=16)
> Group Key: view_time_day
> -> Parallel Seq Scan on base (cost=0.00..280589.00 rows=6000000 width=12)
>
>
> SET max_parallel_degree TO 0;
>
> postgres=# explain SELECT sum(count_i) FROM base GROUP BY view_time_day;
> QUERY PLAN
> -------------------------------------------------------------------------------------------------------------------
> GroupAggregate (cost=0.56..600085.92 rows=31 width=16)
> Group Key: view_time_day
> -> Index Only Scan using base_view_time_day_count_i_idx on base (cost=0.56..450085.61 rows=30000000 width=12)
> (3 rows)
To get good parallelism benefit, the workers has to execute most of
the plan in parallel.
If we run only some part of the upper plan in parallel, we may not get
better parallelism
benefit. At present only seq scan node possible for parallelism at
scan node level.
Index scan is not possible as of now. So because of this reason based
on the overall
cost of the parallel aggregate + parallel seq scan, the plan is chosen.
If index scan is changed to make it parallel in future, it is possible
that parallel aggregate +
parallel index scan plan may chosen.
Regards,
Hari Babu
Fujitsu Australia