On Sun, Jun 21, 2020 at 6:52 PM David Rowley <dgrowleyml@gmail.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