On Sun, Mar 25, 2018 at 09:33:38PM -0400, Peter Eisentraut wrote:
> On 3/21/18 22:38, Michael Paquier wrote:
>> At least on Linux it is possible to rely on sync_file_range which is
>> called via pg_flush_data, so it seems to me that we ought to roughly
>> keep the loop working on FLUSH_DISTANCE, and replace the calls of
>> read/write by copy_file_range. copyfile is only able to do a complete
>> file copy, so we would also lose this property as well on Linux.
>
> I have shown earlier in the thread that copy_file_range in one go is
> still better than doing it in pieces.
f8c183a has introduced the optimization that your patch is removing,
which was discussed on this thread:
https://www.postgresql.org/message-id/flat/4B78906A.7020309%40mark.mielke.cc
I am not much into the internals of copy_file_range, but isn't there a
risk to have a large range of blocks copied to discard potentially
useful blocks from the OS cache? That's what this patch makes me worry
about. Performance is good, but on a system where the OS cache is
heavily used for a set of hot blocks this could cause performance side
effects that I think we canot neglect.
Another thing is that 71d6d07 allowed a couple of database commands to
be more sensitive to interruptions. With large databases used as a base
template it seems to me that this would cause the interruptions to be
less responsive.
--
Michael