Re: Help me develop new commit_delay advice - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Help me develop new commit_delay advice
Date
Msg-id 002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com
Whole thread Raw
In response to Re: Help me develop new commit_delay advice  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
> 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.506ops/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.





pgsql-hackers by date:

Previous
From: "Etsuro Fujita"
Date:
Subject: WIP Patch: Use sortedness of CSV foreign tables for query planning
Next
From: Amit Kapila
Date:
Subject: Issue in Behavior of Interval Datatype