Re: Parallel seq. plan is not coming against inheritance or partition table

On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I also think that commit didn't intend to change the behavior,
> however, the point is how sensible is it to keep such behavior after
> Parallel Append.  I am not sure if this is the right time to consider
> it or shall we wait till Parallel Append is committed.

I think we should wait until that's committed.  I'm not convinced we
ever want to change the behavior, but if we do, let's think about it
then, not now.

> - if (heap_pages < (BlockNumber) min_parallel_table_scan_size &&
> - index_pages < (BlockNumber) min_parallel_index_scan_size &&
> - rel->reloptkind == RELOPT_BASEREL)
> + if (rel->reloptkind == RELOPT_BASEREL &&
> + ((heap_pages >= 0 && heap_pages < min_parallel_table_scan_size) ||
> + (index_pages >= 0 && index_pages < min_parallel_index_scan_size)))
>   return 0;
>
> The purpose of considering both heap and index pages () for
> min_parallel_* is that even if one of them is bigger than threshold
> then we should try parallelism.  This could be helpful for parallel
> index scans where we consider parallel workers based on both heap and
> index pages.  Is there a reason for you to change that condition as
> that is not even related to the problem being discussed?

Really?  We want to do parallelism if EITHER condition is met?  I
thought the goal was to do parallelism if BOTH conditions were met.
Otherwise, you might go parallel if you have a large number of heap
pages but only 1 or 2 index pages.  Preventing that case from using
parallelism was the whole motivation for switching to a two-GUC system
in the first place.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company