Re: large regression for parallel COPY

Hello Robert,

> I tried the same test mentioned in the original post on cthulhu (EDB
> machine, CentOS 7.2, 8 sockets, 8 cores per socket, 2 threads per core,
> Xeon E7-8830 @ 2.13 GHz). I attempted to test both the effects of
> multi_extend_v21 and the *_flush_after settings.

I'm not sure of {backend,writer}_flush_after intrinsic effectiveness,
especially on HDDs, because although for the checkpointer
(checkpoint_flush_after) there is a great deal of effort to generate large
sequential writes, there is no such provisions for other write activities.
I'm not sure how the write activity of the "parallel" copy is organized,
but that sounds like it will generate less sequential writes than before,
and the negative performance impact could be accentuated by flushing.

This might suggest that the benefit of these two settings are more
irregular/hard to predict, so their default value should be 0 (aka off)?

Or maybe warn clearly in the documentation about the uncertain effects of
these two settings?

--
Fabien.