From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, menjo(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp, ishizaki(dot)teruaki(at)lab(dot)ntt(dot)co(dot)jp |
Subject: | Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory |
Date: | 2018-11-29 17:48:12 |
Message-ID: | CA+q6zcVoGWCU4dNE9zYM5jVWEwNHiTQO_fkCmCWzekN1-gz3OA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Tue, Oct 2, 2018 at 4:53 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
> > The libpmem's pmem_map_file() supported 2M/1G(the size of huge page)
> > alignment, since it could reduce the number of page faults.
> > In addition, libpmem's pmem_memcpy_nodrain() is the function
> > to copy data using single instruction, multiple data(SIMD) instructions
> > and NT store instructions(MOVNT).
> > As a result, using these APIs is faster than using old mmap()/memcpy().
> >
> > Please see the PGCon2018 presentation[1] for the details.
> >
> > [1] https://www.pgcon.org/2018/schedule/attachments/507_PGCon2018_Introducing_PMDK_into_PostgreSQL.pdf
>
> So you say that this represents a 3% gain based on the presentation?
> That may be interesting to dig into it. Could you provide fresher
> performance numbers? I am moving this patch to the next CF 2018-10 for
> now, waiting for input from the author.
Unfortunately, the patch has some conflicts now, so probably not only fresher
performance numbers are necessary, but also a rebased version.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2018-11-29 17:58:07 | Re: de-deduplicate code in DML execution hooks in postgres_fdw |
Previous Message | Alvaro Herrera | 2018-11-29 17:47:41 | Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements |