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

On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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