Re: large regression for parallel COPY

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: large regression for parallel COPY
Дата
Msg-id alpine.DEB.2.10.1604060841310.25561@sto
обсуждение исходный текст
Ответ на Re: large regression for parallel COPY  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Timeline following for logical slots
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Timeline following for logical slots