pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Amit Kapila <amit.kapila@huawei.com>
To: 'Peter Geoghegan' <peter@2ndquadrant.com>
Cc: 'PG Hackers' <pgsql-hackers@postgresql.org>
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> (raw)
In-Reply-To: <CAEYLb_WmUjTLctsJKTCCO+VVKpKa=tWywEhkRP9D6k=hOPSs+w@mail.gmail.com>
References: <CAEYLb_WtD+Ew3k6RZuL6ydsowoYbMKJWa6w+cNH-kzngAzN16g@mail.gmail.com>
	<-5853706607335123168@unknownmsgid>
	<CAEYLb_WmUjTLctsJKTCCO+VVKpKa=tWywEhkRP9D6k=hOPSs+w@mail.gmail.com>

> 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.






view thread (9+ messages)  latest in thread

Message-ID: <002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com>
Permalink:  ../002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com/
Also on:    postgresql.org/message-id/002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: amit.kapila@huawei.com, peter@2ndquadrant.com, pgsql-hackers@postgresql.org
  Subject: Re: Help me develop new commit_delay advice
  In-Reply-To: <002401cd70a0$1837a2b0$48a6e810$@kapila@huawei.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox