Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0733D65016D for ; Mon, 1 Sep 2008 17:42:19 -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 28227-01 for ; Mon, 1 Sep 2008 17:42:10 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by postgresql.org (Postfix) with ESMTP id 56343650111 for ; Mon, 1 Sep 2008 17:42:08 -0300 (ADT) Received: by rv-out-0506.google.com with SMTP id b25so2786968rvf.43 for ; Mon, 01 Sep 2008 13:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=5fKWDzxNZ+GN7bH969b0yeQYV38hb5dA1ZlgG/3hVvg=; b=JmqzdW3wPQg88ByVSZuGFMHaBwPI3hRwf3O/tdr3xD5oBygoUUEY4/LtfDeG3nojDG ioxbT/pE7K4iBlAOoUHCMDT1J4ihKmXm2SsGcSETaSHeqXAUWFUvx9236HfAHV5wE0iA ZHC5xWefZGWwDVh1SBb5RqrRONJdpM0IQCzaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=EYI4H9RlfXpoHFvTYOFdP9j0O31udiKrtCnFhUcLLWotwGBucR1gPe6kW5UUEnlIJa 9jHgEjxZpqVOWaq5Evkel+qc6UZdsAON/NWbVE4kaKh/dOhJefbCEh4iU4bc9eIL8HDI RxbdD3dhw0ick6FRsFlNlebVwwbuaTUyz9Uq0= Received: by 10.141.195.5 with SMTP id x5mr3664631rvp.263.1220301727147; Mon, 01 Sep 2008 13:42:07 -0700 (PDT) Received: by 10.140.248.12 with HTTP; Mon, 1 Sep 2008 13:42:07 -0700 (PDT) Message-ID: Date: Mon, 1 Sep 2008 14:42:07 -0600 From: "Scott Marlowe" To: "Thomas Finneid" Subject: Re: slow update of index during insert/copy Cc: "Scott Carey" , "Craig Ringer" , pgsql-performance@postgresql.org In-Reply-To: <48BC5178.60906@ifi.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48BA9D65.2020001@ifi.uio.no> <48BB4A2D.9080404@postnewspapers.com.au> <48BBD22E.4090308@ifi.uio.no> <48BC5178.60906@ifi.uio.no> 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/16 X-Sequence-Number: 31329 On Mon, Sep 1, 2008 at 2:32 PM, Thomas Finneid wrote: > > Scott Carey wrote: >> >> For a development box, just enable write-back caching regardless of the >> battery back up situation. As long as its not your only copy of > > Will have a look at it, the data is not important and can be reproduced any > time on any machine. The controller I have is a Areca ARC-1220 Serial ATA 8 > port RAID Controller - PCI-E, SATA II, so I dont know exactly what it > supports of caching. It's a pretty good card. It should support 1G of cache at least, and definitely supports battery backup. Have had a pair of 1680 Arecas in production for a month now and so far I'm very happy with the reliability and performance. The other Scott is technically right about the lack of need for battery back on a dev machine as long as you go in and change the chaching to write back, and I'm sure the card will give you a red dialog box saying this is a bad idea. Now, if it would take you a day of downtime to get a dev database back in place and running after a power loss, then the bbu may be worth the $200 or so. While I like to have a machine kitted out just like prod for testing, for development I do tend to prefer slower machines, so that developers might notice if they've just laid a big fat bloaty code egg that's slower than it should be. Try to optimize for acceptable performance on such server and you're far more likely to get good performance behaviour in production.