Skip site navigation (1) Skip section navigation (2)

Re: Linux Filesystems again - Ubuntu this time

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Whit Armstrong" <armstrong(dot)whit(at)gmail(dot)com>
Cc: "Mark Kirkwood" <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Linux Filesystems again - Ubuntu this time
Date: 2010-07-27 18:32:18
Message-ID: 4C4EDFE20200002500033DA1@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-performance
Whit Armstrong <armstrong(dot)whit(at)gmail(dot)com> wrote:
 
> But there is no such risk to turning off write barriers?
 
Supposedly not:
 
http://xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.3F
 
> Did you get a substantial performace boost from disabling write
> barriers?  like 10x or more like 2x?
 
It made a huge difference on creation and deletion of disk files. 
Unfortunately we have some procedures which use a cursor and loop
through rows calling a function which creates and drops a temporary
table.  While I would like to see those transactions rewritten to
use sane techniques, they run fast enough without the write barriers
to be acceptable to the users, which puts the issue pretty low on
the priority list.  I don't have the numbers anymore, but I'm sure
it was closer to 100 times slower than 10 times.  In some workloads
you might not notice the difference, although I would watch out for
checkpoint behavior.
 
-Kevin

In response to

pgsql-performance by date

Next:From: Greg SpiegelbergDate: 2010-07-27 20:02:08
Subject: Re: how to handle a big table for data log
Previous:From: Tom LaneDate: 2010-07-27 18:25:25
Subject: Re: potential performance gain by query planner optimization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group