Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7414337D2B1 for ; Sun, 28 Sep 2008 06:06:24 -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 76677-03-5 for ; Sun, 28 Sep 2008 06:06:20 -0300 (ADT) Received: from mx3.hub.org (mx3.hub.org [206.223.169.73]) by postgresql.org (Postfix) with ESMTP id 0BB0D37BFDB for ; Sun, 28 Sep 2008 06:06:13 -0300 (ADT) X-Greylist: delayed 00:05:04.923451 by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx3.hub.org (Postfix) with ESMTP id 1074C37B79D for ; Sat, 27 Sep 2008 19:59:26 -0300 (ADT) Received: by rv-out-0506.google.com with SMTP id b25so1388882rvf.43 for ; Sat, 27 Sep 2008 15:59:25 -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=2VRmqp+g56oe+uDOmyPSsV8/Wxnk6ik0z/ipqDtoF1k=; b=xK48gQDFohccObomtwCGeDiVKAFDQV89obLoI3RxVWMuK14tERw4LRAA+ksXK+o4Qq 78b2rJt8v88qqBWMDb1z8n3yV0dHLmZdldT0EA97R4tFyBTjiffl2YGIepnniOKnHncp DHShGzzB+DvTNlMsLDlbBCWMW3KUf8IYDiTmI= 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=ISM8Ti/813a2Lm4UqbnIHeogKoX3pKg6GvrQhLSZt1QxcJTRtlElv4PWDwzXLhwEaB ytqSwUQYqCS9j++CuB+i6WvgPsgCA6qjp02szUq2inXcQWZpfcsbppAd5H4djyPgtMb2 O9n8tF+lF3PcBEmU+fOWFbEAfhKHbfcgEGEso= Received: by 10.141.161.6 with SMTP id n6mr1566892rvo.41.1222556060764; Sat, 27 Sep 2008 15:54:20 -0700 (PDT) Received: by 10.140.248.12 with HTTP; Sat, 27 Sep 2008 15:54:20 -0700 (PDT) Message-ID: Date: Sat, 27 Sep 2008 16:54:20 -0600 From: "Scott Marlowe" To: "John Huttley" Subject: Re: Slow updates, poor IO Cc: pgsql-performance@postgresql.org In-Reply-To: <48DEB4D4.1020100@mib-infotech.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48DBE587.3050406@mib-infotech.co.nz> <20080926131556.GA1005@commandprompt.com> <48DD6A4A.10209@mib-infotech.co.nz> <48DEB4D4.1020100@mib-infotech.co.nz> 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/240 X-Sequence-Number: 31553 On Sat, Sep 27, 2008 at 4:33 PM, John Huttley wrote: > > > > this is part of the trade-offs of MVCC. > > > was... was a part of the trade-offs. > > You are thinking of HOT? > I don't think it applies in the case of full table updates?? Sure, you just need a table with plenty of empty space in it, either from vacuumed previous deletes / inserts or with a low fill factor like 50%. > It's really an effect of parallel updates / writes / accesses, and is > always an issue for a database running on a poor storage subsystem. A > db with a two drive mirror set is always going to be at a disadvantage > to one running on a dozen or so drives in a RAID-10 > > Oh well, I'm forever going to be disadvantaged. Why? A decent caching raid controller and a set of 4 to 8 SATA drives can make a world of difference and the cost is not that high for the gain in performance. Even going to 4 drives in a software RAID-10 can make a lot of difference in these situations, and that can be done with spare machines and hard drives.