Re: Parallel Seq Scan vs kernel read ahead

On Fri, Jun 12, 2020 at 11:28 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Jun 11, 2020 at 4:54 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > I think someone at some point is not going to like the automatic
> > choice. So perhaps a reloption to allow users to overwrite it is a
> > good idea. -1 should most likely mean use the automatic choice based
> > on relation size. I think for parallel seq scans that filter a large
> > portion of the records most likely need some sort of index, but there
> > are perhaps some genuine cases for not having one. e.g perhaps the
> > query is just not run often enough for an index to be worthwhile. In
> > that case, the performance is likely less critical, but at least the
> > reloption would allow users to get the old behaviour.
>
> Let me play the devil's advocate here. I feel like if the step size is
> limited by the relation size and there is ramp-up and ramp-down, or
> maybe even if you don't have all 3 of those but perhaps say 2 of them,
> the chances of there being a significant downside from using this seem
> quite small. At that point I wonder whether you really need an option.
> It's true that someone might not like it, but there are all sorts of
> things that at least one person doesn't like and one can't cater to
> all of them.
>
> To put that another way, in what scenario do we suppose that a
> reasonable person would wish to use this reloption?
>

The performance can vary based on qualification where some workers
discard more rows as compared to others, with the current system with
step-size as one, the probability of unequal work among workers is
quite low as compared to larger step-sizes.

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