Re: Parallel Seq Scan vs kernel read ahead

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Seq Scan vs kernel read ahead
Date: 2020-06-11 02:08:53
Message-ID: CAA4eK1+ojEvW3R3Ysrr6iUWwcUx56ddH8+L111t2_EQwd2jmkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 11, 2020 at 7:18 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 11 Jun 2020 at 01:24, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Can we try the same test with 4, 8, 16 workers as well? I don't
> > foresee any problem with a higher number of workers but it might be
> > better to once check that if it is not too much additional work.
>
> I ran the tests again with up to 7 workers. The CPU here only has 8
> cores (a laptop), so I'm not sure if there's much sense in going
> higher than that?
>

I think it proves your point that there is a value in going for step
size greater than 64. However, I think the difference at higher sizes
is not significant. For example, the difference between 8192 and
16384 doesn't seem much if we leave higher worker count where the data
could be a bit misleading due to variation. I could see that there is
a clear and significant difference till 1024 but after that difference
is not much.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 曾文旌 2020-06-11 02:13:08 Re: [Proposal] Global temporary tables
Previous Message David Rowley 2020-06-11 01:47:49 Re: Parallel Seq Scan vs kernel read ahead