Re: large regression for parallel COPY - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: large regression for parallel COPY
Date
Msg-id alpine.DEB.2.10.1604060841310.25561@sto
Whole thread Raw
In response to Re: large regression for parallel COPY  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Timeline following for logical slots
Next
From: Craig Ringer
Date:
Subject: Re: Timeline following for logical slots