Re: Compression of full-page-writes
От | KONDO Mitsumasa |
---|---|
Тема | Re: Compression of full-page-writes |
Дата | |
Msg-id | 52494E4B.20604@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Compression of full-page-writes (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
(2013/09/30 13:55), Amit Kapila wrote: > On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao <masao.fujii@gmail.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
В списке pgsql-hackers по дате отправления: