On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
>> 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.
>
> That's a separate problem. I think we ought to consider having an
> index-only scan pass -1 for the number of heap pages, so that the
> degree of parallelism in that case is limited only by the number of
> index pages.
>
Sure, that sounds sensible, but even after that, I am not sure if for
plain index scans it is a good idea to not choose parallelism if the
number of heap pages is lesser than min_parallel_table_scan_size even
though the number of index pages is greater than
min_parallel_index_scan_size. I think we can try out some tests
(maybe TPC-H queries where parallel index scan gets picked up) to see
what is right here. Do you think it will be bad if just commit your
patch without this change and then consider changing it separately?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
