Re: Help me develop new commit_delay advice

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Peter Geoghegan'" <peter(at)2ndquadrant(dot)com>
Cc: "'PG Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Help me develop new commit_delay advice
Date: 2012-08-02 11:15:15
Message-ID: 002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

> From: Peter Geoghegan [mailto:peter(at)2ndquadrant(dot)com]
> Sent: Wednesday, August 01, 2012 8:49 PM

On 1 August 2012 15:14, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> I shall look into this aspect also(setting commit_delay based on raw
sync).
>> You also suggest if you want to run the test with different
configuration.

> Well, I was specifically interested in testing if half of raw sync
> time was a widely useful setting, across a variety of different,
> though representative I/O subsystems. Unfortunately, without some
> context about raw sync speed to go along with your numbers, I cannot
> advance or disprove that idea.

Raw sync speed data
--------------------------
2 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync n/a
fdatasync 165.506 ops/sec
fsync 166.647 ops/sec
fsync_writethrough n/a
open_sync 164.654 ops/sec

165.506 * 8KB operations can perform in one sec.
so 1 * 8KB operation takes 6.042 msec.

> It would also have been nice to see a baseline number of 0 too, to get
> an idea of how effective commit_delay may now be. However, that's
> secondary.

In the data sent yesterday commit_delay=0 was there.

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2012-08-02 13:08:31 Issue in Behavior of Interval Datatype
Previous Message Etsuro Fujita 2012-08-02 11:01:27 WIP Patch: Use sortedness of CSV foreign tables for query planning

Browse pgsql-performance by date

  From Date Subject
Next Message Russell Keane 2012-08-02 14:54:50 query using incorrect index
Previous Message Kevin Grittner 2012-08-01 16:42:28 Re: Using ctid column changes plan drastically