Re: Parallel Seq Scan vs kernel read ahead

On Fri, Jun 12, 2020 at 2:24 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 11 Jun 2020 at 23:35, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Another point I am thinking is that whatever formula we come up here
> > might not be a good fit for every case. For ex. as you mentioned
> > above that larger step-size can impact the performance based on
> > qualification, similarly there could be other things like having a
> > target list or qual having some function which takes more time for
> > certain tuples and lesser for others especially if function evaluation
> > is based on some column values. So, can we think of providing a
> > rel_option for step-size?
>
> 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.
>

makes sense to me.

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