From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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-18 23:34:15 |
Message-ID: | CAApHDvoWv_-QG7R8p=uDEvjYAEKTTKG-r9Ak8zdZr_w-7hspRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 19 Jun 2020 at 03:26, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Jun 18, 2020 at 6:15 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > With a 32TB relation, the code will make the chunk size 16GB. Perhaps
> > I should change the code to cap that at 1GB.
>
> It seems pretty hard to believe there's any significant advantage to a
> chunk size >1GB, so I would be in favor of that change.
I could certainly make that change. With the standard page size, 1GB
is 131072 pages and a power of 2. That would change for non-standard
page sizes, so we'd need to decide if we want to keep the chunk size a
power of 2, or just cap it exactly at whatever number of pages 1GB is.
I'm not sure how much of a difference it'll make, but I also just want
to note that synchronous scans can mean we'll start the scan anywhere
within the table, so capping to 1GB does not mean we read an entire
extent. It's more likely to span 2 extents.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-06-18 23:51:13 | Re: Add A Glossary |
Previous Message | Tom Lane | 2020-06-18 23:17:34 | Re: More tzdb fun: POSIXRULES is being deprecated upstream |