Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 14002650235 for ; Mon, 1 Sep 2008 16:42:04 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 14814-10 for ; Mon, 1 Sep 2008 16:41:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by postgresql.org (Postfix) with ESMTP id 192FB650216 for ; Mon, 1 Sep 2008 16:41:55 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id 29so1658874ugo.7 for ; Mon, 01 Sep 2008 12:41:53 -0700 (PDT) Received: by 10.66.221.19 with SMTP id t19mr3003852ugg.69.1220298113521; Mon, 01 Sep 2008 12:41:53 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ( [87.127.95.198]) by mx.google.com with ESMTPS id l20sm3830315uga.16.2008.09.01.12.41.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Sep 2008 12:41:52 -0700 (PDT) To: "Scott Carey" Cc: "Scott Marlowe" , "Thomas Finneid" , "Craig Ringer" , pgsql-performance@postgresql.org Subject: Re: slow update of index during insert/copy In-Reply-To: (Scott Carey's message of "Mon\, 1 Sep 2008 11\:46\:59 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 743) References: <48BA9D65.2020001@ifi.uio.no> <48BB4A2D.9080404@postnewspapers.com.au> <48BBD22E.4090308@ifi.uio.no> From: Gregory Stark Organization: EnterpriseDB Date: Mon, 01 Sep 2008 20:41:48 +0100 Message-ID: <873akjodqb.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/13 X-Sequence-Number: 31326 "Scott Carey" writes: > On Raid Controllers and Dev machines: > > For a dev machine the battery backup is NOT needed. > > Battery back up makes a _production_ system faster: In production, data > integrity is everything, and write-back caching is dangerous without a > battery back up. > > So: > Without BBU: Write-through cache = data safe in power failure; Write back > cache = not safe in power failure. > With BBU : Both modes are safe on power loss. This could be read the wrong way. With a BBU it's not that you can run the drives in write-back mode safely. It's that you can cache in the BBU safely. The drives still need to have their write caches off (ie, in write-through mode). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!