Re: [HACKERS] Parallel Index Scans - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Parallel Index Scans
Date
Msg-id CAA4eK1JARdXXZpsaaSjnBDtzhfJW5RyrfRBujNesKNbbAJmHuQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Index Scans  (Rahila Syed <rahilasyed90@gmail.com>)
Responses Re: [HACKERS] Parallel Index Scans  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jan 31, 2017 at 5:53 PM, Rahila Syed <rahilasyed90@gmail.com> wrote:
> Hello,
>
>>Agreed, that it makes sense to consider only the number of pages to
>>scan for computation of parallel workers.  I think for index scan we
>>should consider both index and heap pages that need to be scanned
>>(costing of index scan consider both index and heap pages).   I thin
>>where considering heap pages matter more is when the finally selected
>>rows are scattered across heap pages or we need to apply a filter on
>>rows after fetching from the heap.  OTOH, we can consider just pages
>>in the index as that is where mainly the parallelism works
> IMO, considering just index pages will give a better estimate of work to be
> done
> in parallel. As the amount of work/number of pages divided amongst workers
> is irrespective of
> the number of heap pages scanned.
>

Yeah, I understand that point and I can see there is strong argument
to do that way, but let's wait and see what others including Robert
have to say about this point.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] asynchronous execution
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument