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
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 |