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