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

On Wed, Mar 8, 2017 at 7:04 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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?

No, I think that would be fine. I think that we need to commit
something like what I proposed because the earlier commit broke
something that used to work. That's got to get fixed. Now if we
subsequently find out that what we've implemented can be improved in
some way, we can consider those changes then.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company