Re: Compression of full-page-writes

From: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compression of full-page-writes
Date: 2013-09-30 10:11:23
Message-ID: 52494E4B.20604@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2013/09/30 13:55), Amit Kapila wrote:
> On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Yep, please! It's really helpful!
OK! I test with single instance and synchronous replication constitution.

By the way, you posted patch which is sync_file_range() WAL writing method in 3
years ago. I think it is also good for performance. As the reason, I read
sync_file_range() and fdatasync() in latest linux kernel code(3.9.11),
fdatasync() writes in dirty buffers of the whole file, on the other hand,
sync_file_range() writes in partial dirty buffers. In more detail, these
functions use the same function in kernel source code, fdatasync() is
vfs_fsync_range(file, 0, LLONG_MAX, 1), and sync_file_range() is
vfs_fsync_range(file, offset, amount, 1).
It is obvious that which is more efficiently in WAL writing.

You had better confirm it in linux kernel's git. I think your conviction will be
more deeply.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/sync.c?id=refs/tags/v3.11.2

> I think it will be useful if you can get the data for 1 and 2 threads
> (may be with pgbench itself) as well, because the WAL reduction is
> almost sure, but the only thing is that it should not dip tps in some
> of the scenarios.
That's right. I also want to know about this patch in MD environment, because
MD has strong point in sequential write which like WAL writing.

Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-09-30 10:22:54 Re: proposal: lob conversion functionality
Previous Message Heikki Linnakangas 2013-09-30 10:06:15 Re: proposal: lob conversion functionality