On Tue, Mar 7, 2017 at 10:12 PM, Robert Haas <robertmh...@gmail.com> wrote: > 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. >
If we have lesser index pages and more heap pages, then we limit the parallelism based on index pages. I think it can give us benefit in such cases as well (especially when we have to discard rows based heap rows). Now, consider it from another viewpoint, what if there are enough index pages (> min_parallel_index_scan_size) but not sufficient heap pages. I think in such cases parallel index (only) scans will be beneficial especially because in the parallel index only scans heap_pages could be very less or possibly could be zero. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
