Re: WAL prefetch - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: WAL prefetch
Date
Msg-id CAA4eK1LphkWoc5mK5j5SmHU9NDFOpTuvCW9ddzbQA1gEg_B_Yg@mail.gmail.com
Whole thread Raw
In response to Re: WAL prefetch  (Stephen Frost <sfrost@snowman.net>)
Responses Re: WAL prefetch
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: automating perl compile time checking
Next
From: "Ideriha, Takeshi"
Date:
Subject: RE: ON CONFLICT DO NOTHING on pg_dump