> 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 the problem here is that compute_parallel_worker() thinks it >> can use 0 as a sentinel value that means "ignore this", but it can't >> really, because a heap can actually contain 0 pages. Here's a patch >> which does the following: >> > > - 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.
Yes, But, this is only true for normal tables not for partitioned or inheritance tables. I think for partition table, even if one heap page exist, we go for 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? > I think he has changed to allow parallelism for inheritance or partition tables. For normal tables, it won't be touched until the below if-condition is satisfied. *if (heap_pages < (BlockNumber) min_parallel_table_scan_size && index_pages < (BlockNumber) min_parallel_index_scan_size && rel->reloptkind == RELOPT_BASEREL) return 0;* -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com
