Re: Parallel Index Scans

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: Anastasia Lubennikova <lubennikovaav@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Rahila Syed <rahilasyed.90@gmail.com>
Date: 2017-01-15T04:11:38Z
Lists: pgsql-hackers
On Fri, Jan 13, 2017 at 7:58 PM, Anastasia Lubennikova
<a.lubennikova@postgrespro.ru> wrote:
> 27.12.2016 17:33, Amit Kapila:
>
>
> The similar problem has occurred while testing "parallel index only
> scan" patch and Rafia has included the fix in her patch [1] which
> ideally should be included in this patch, so I have copied the fix
> from her patch.  Apart from that, I observed that similar problem can
> happen for backward scans, so fixed the same as well.
>
>
> I confirm that this problem is solved.
>
> But I'm trying to find the worst cases for this feature. And I suppose we
> should test parallel index scans with
> concurrent insertions. More parallel readers we have, higher the
> concurrency.
> I doubt that it can significantly decrease performance, because number of
> parallel readers is not that big,
>
> I am not sure if such a test is meaningful for this patch because
> parallelism is generally used for large data reads and in such cases
> there are generally not many concurrent writes.
>
>
> I didn't find any case of noticeable performance degradation,
> so set status to "Ready for committer".
>

Thank you for the review!


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


Commits

  1. Replace min_parallel_relation_size with two new GUCs.

  2. Factor out logic for computing number of parallel workers.

  3. Support condition variables.

  4. Allow parallel custom and foreign scans.

  5. Add a C API for parallel heap scans.