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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>
Subject: Re: Parallel seq. plan is not coming against inheritance or partition table
Date: 2017-03-08 02:24:33
Message-ID: CAA4eK1KUCmSqLpTvHJo0QzWdWUw4SaNSffL+Vi4V6ZGxeAtVjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 7, 2017 at 10:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-03-08 02:29:19 Re: Enabling replication connections by default in pg_hba.conf
Previous Message David Rowley 2017-03-08 02:19:34 Re: PATCH: two slab-like memory allocators