Re: Parallel Seq Scan vs kernel read ahead - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Parallel Seq Scan vs kernel read ahead
Date
Msg-id CA+hUKGLD7FeyDkDbCU3=kkt30QdBuARv529PM=E5NsfGKr18Ug@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel Seq Scan vs kernel read ahead  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
On Wed, May 20, 2020 at 2:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> Good experiment.  IIRC, we have discussed a similar idea during the
> development of this feature but we haven't seen any better results by
> allocating in ranges on the systems we have tried.  So, we want with
> the current approach which is more granular and seems to allow better
> parallelism.  I feel we need to ensure that we don't regress
> parallelism in existing cases, otherwise, the idea sounds promising to
> me.

Yeah, Linux seems to do pretty well at least with smallish numbers of
workers, and when you use large numbers you can probably tune your way
out of the problem.  ZFS seems to do fine.  I wonder how well the
other OSes cope.



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platformwd
Next
From: Justin Pryzby
Date:
Subject: Re: Warn when parallel restoring a custom dump without data offsets