Re: fallocate / posix_fallocate for new WAL file creation (etc...) - Mailing list pgsql-hackers

From Greg Smith
Subject Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Date
Msg-id 51D0C400.1080001@2ndQuadrant.com
Whole thread Raw
In response to Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Responses Re: fallocate / posix_fallocate for new WAL file creation (etc...)
List pgsql-hackers
On 5/28/13 10:00 PM, Jon Nelson wrote:

> A note: The attached test program uses *fsync* instead of *fdatasync*
> after calling fallocate (or writing out 16MB of zeroes), per an
> earlier suggestion.

I tried this out on the RHEL5 platform I'm worried about now.  There's 
something weird about the test program there.  If I run it once it shows 
posix_fallocate running much faster:

without posix_fallocate: 1 open/close iterations, 1 rewrite in 23.0169s
with posix_fallocate: 1 open/close iterations, 1 rewrite in 11.1904s

The problem is that I'm seeing the gap between the two get smaller the 
more iterations I run, which makes me wonder if the test is completely fair:

without posix_fallocate: 2 open/close iterations, 2 rewrite in 34.3281s
with posix_fallocate: 2 open/close iterations, 2 rewrite in 23.1798s

without posix_fallocate: 3 open/close iterations, 3 rewrite in 44.4791s
with posix_fallocate: 3 open/close iterations, 3 rewrite in 33.6102s

without posix_fallocate: 5 open/close iterations, 5 rewrite in 65.6244s
with posix_fallocate: 5 open/close iterations, 5 rewrite in 61.0991s

You didn't show any output from the latest program on your system, so 
I'm not sure how it behaved for you here.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Jon Nelson
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Michael Paquier
Date:
Subject: Re: Support for REINDEX CONCURRENTLY