On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
