Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? - Mailing list pgsql-performance

From Greg Smith
Subject Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
Date
Msg-id 4CE45BBF.7000507@2ndquadrant.com
Whole thread Raw
In response to Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?  (Jon Nelson <jnelson+pgsql@jamponi.net>)
List pgsql-performance
Jon Nelson wrote:
> One thing to note is that where on a disk things sit can make a /huge/
> difference - depending on if Ubuntu is /here/ and RHEL is /there/ and
> so on can make a factor of 2 or more difference.  The outside tracks
> of most modern SATA disks can do around 120MB/s. The inside tracks
> aren't even half of that.
>

You're talking about changes in sequential read and write speed due to
Zone Bit Recording (ZBR) AKA Zone Constant Angular Velocity (ZCAV).
What I was measuring was commit latency time on small writes.  That
doesn't change as you move around the disk, since it's tied to the raw
rotation speed of the drive rather than density of storage in any zone.
If I get to something that's impacted by sequential transfers rather
than rotation time, I'll be sure to use the same section of disk for
that.  It wasn't really necessary to get these initial gross numbers
anyway.  What I was looking for is the about 10:1 speedup seen on this
hardware when the write cache is used, which could easily be seen even
were there ZBR differences involved.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


pgsql-performance by date:

Previous
From: Mladen Gogala
Date:
Subject: Re: Query Performance SQL Server vs. Postgresql
Next
From: Ivan Voras
Date:
Subject: Re: Anyone seen this kind of lock pileup?