From: Amit Kapila <amit.kapila@huawei.com>
To: "'Peter Geoghegan'" <peter@2ndquadrant.com>
CC: "'PG Hackers'" <pgsql-hackers@postgresql.org>
References: 
 <CAEYLb_WtD+Ew3k6RZuL6ydsowoYbMKJWa6w+cNH-kzngAzN16g@mail.gmail.com>
	<-5853706607335123168@unknownmsgid>
	<CAEYLb_WmUjTLctsJKTCCO+VVKpKa=tWywEhkRP9D6k=hOPSs+w@mail.gmail.com>
In-Reply-To: 
 <CAEYLb_WmUjTLctsJKTCCO+VVKpKa=tWywEhkRP9D6k=hOPSs+w@mail.gmail.com>
Subject: Re: Help me develop new commit_delay advice
Date: Thu, 2 Aug 2012 16:45:15 +0530
Message-ID: <002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac1v+Q9t+k625kHkRd+GvJmTroBy7gAfmQjw
Content-Language: en-us

> From: Peter Geoghegan [mailto:peter@2ndquadrant.com] 
> Sent: Wednesday, August 01, 2012 8:49 PM

On 1 August 2012 15:14, Amit Kapila <amit.kapila@huawei.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.