On Fri, Jun 26, 2020 at 3:33 AM Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jun 23, 2020 at 11:53 PM David Rowley <dgrowle...@gmail.com> wrote: > > In summary, based on these tests, I don't think we're making anything > > worse in regards to synchronize_seqscans if we cap the maximum number > > of blocks to allocate to each worker at once to 8192. Perhaps there's > > some argument for using something smaller than that for servers with > > very little RAM, but I don't personally think so as it still depends > > on the table size and It's hard to imagine tables in the hundreds of > > GBs on servers that struggle with chunk allocations of 16MB. The > > table needs to be at least ~70GB to get a 8192 chunk size with the > > current v2 patch settings. > > Nice research. That makes me happy. I had a feeling the maximum useful > chunk size ought to be more in this range than the larger values we > were discussing before, but I didn't even think about the effect on > synchronized scans.
+1. This seems about right to me. We can always reopen the discussion if someone shows up with evidence in favour of a tweak to the formula, but this seems to address the basic problem pretty well, and also fits nicely with future plans for AIO and DIO.
