| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sean Chittenden <seanc(at)joyent(dot)com> |
| Subject: | Re: WAL prefetch |
| Date: | 2018-06-15 04:36:56 |
| Message-ID: | CAA4eK1LphkWoc5mK5j5SmHU9NDFOpTuvCW9ddzbQA1gEg_B_Yg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 15, 2018 at 12:16 AM, Stephen Frost <sfrost(at)snowman(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ideriha, Takeshi | 2018-06-15 05:06:25 | RE: ON CONFLICT DO NOTHING on pg_dump |
| Previous Message | Peter Eisentraut | 2018-06-15 04:21:07 | Re: automating perl compile time checking |