From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(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-22 14:20:02 |
Message-ID: | CA+TgmoZ6C0189RgVHdtsomLa8h5ru0AwAWiQaqwPw=x56qX5iQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 21, 2020 at 6:52 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> Perhaps that's not a problem though, but then again, perhaps just
> keeping it at 131072 regardless of RELSEG_SIZE and BLCKSZ is also ok.
> The benchmarks I did on Windows [1] showed that the returns diminished
> once we started making the step size some decent amount so my thoughts
> are that I've set PARALLEL_SEQSCAN_MAX_CHUNK_SIZE to something large
> enough that it'll make no difference to the performance anyway. So
> there's probably not much point in giving it too much thought.
>
> Perhaps pg_nextpower2_32(RELSEG_SIZE) would be okay though.
I guess I don't care that much; it was just a thought. Maybe tying it
to RELSEG_SIZE is a bad idea anyway. After all, what if we find cases
where 1GB is too much? Like, how much benefit do we get from making it
1GB rather than 64MB, say? I don't think we should be making this
value big just because we can.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-06-22 14:27:18 | Update InsertPgAttributeTuple comment to match new signature |
Previous Message | Tomas Vondra | 2020-06-22 14:19:00 | Re: [PATCH] Initial progress reporting for COPY command |