Re: WAL prefetch

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: WAL prefetch
Дата
Msg-id CAA4eK1LphkWoc5mK5j5SmHU9NDFOpTuvCW9ddzbQA1gEg_B_Yg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WAL prefetch  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: WAL prefetch  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
On Fri, Jun 15, 2018 at 12:16 AM, Stephen Frost <sfrost@snowman.net> wrote:
>
>> I have tested wal_prefetch at two powerful servers with 24 cores, 3Tb NVME
>> RAID 10 storage device and 256Gb of RAM connected using InfiniBand.
>> The speed of synchronous replication between two nodes is increased from 56k
>> TPS to 60k TPS (on pgbench with scale 1000).
>
> I'm also surprised that it wasn't a larger improvement.
>
> Seems like it would make sense to implement in core using
> posix_fadvise(), perhaps in the wal receiver and in RestoreArchivedFile
> or nearby..  At least, that's the thinking I had when I was chatting w/
> Sean.
>

Doing in-core certainly has some advantage such as it can easily reuse
the existing xlog code rather trying to make a copy as is currently
done in the patch, but I think it also depends on whether this is
really a win in a number of common cases or is it just a win in some
limited cases.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: automating perl compile time checking
Следующее
От: "Ideriha, Takeshi"
Дата:
Сообщение: RE: ON CONFLICT DO NOTHING on pg_dump