Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 8796764FC32 for ; Thu, 25 Sep 2008 16:25:16 -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 86170-01 for ; Thu, 25 Sep 2008 16:25:09 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gatekeeper.Mib-infotech.co.nz (60-234-154-229.bitstream.orcon.net.nz [60.234.154.229]) by postgresql.org (Postfix) with ESMTP id 4D48164FC01 for ; Thu, 25 Sep 2008 16:25:08 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by gatekeeper.Mib-infotech.co.nz (Postfix) with ESMTP id E48FD10C6F3; Fri, 26 Sep 2008 07:25:03 +1200 (NZST) X-Virus-Scanned: amavisd-new at mib-infotech.co.nz Received: from gatekeeper.Mib-infotech.co.nz ([127.0.0.1]) by localhost (gatekeeper.mib-infotech.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYAjQymd-iG6; Fri, 26 Sep 2008 07:24:56 +1200 (NZST) Received: from [192.168.95.202] (mr-creosote.mib-infotech.co.nz [192.168.95.202]) by gatekeeper.Mib-infotech.co.nz (Postfix) with ESMTPA id D439210C6F0; Fri, 26 Sep 2008 07:24:55 +1200 (NZST) Message-ID: <48DBE587.3050406@mib-infotech.co.nz> Date: Fri, 26 Sep 2008 07:24:55 +1200 From: John Huttley User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: pgsql-performance@postgresql.org CC: Dan Langille Subject: Slow updates, poor IO Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.715 tagged_above=0 required=5 tests=RCVD_IN_SORBS_DUL=1.615, RDNS_DYNAMIC=0.1 X-Spam-Level: * X-Archive-Number: 200809/225 X-Sequence-Number: 31538 I've just had an interesting encounter with the slow full table update problem that is inherent with MVCC The system is 64 bit linux with 2.6.25 kernel feeding scsi disks. the table is CREATE TABLE file ( fileid integer NOT NULL, fileindex integer DEFAULT 0 NOT NULL, jobid integer NOT NULL, pathid integer NOT NULL, filenameid integer NOT NULL, markid integer DEFAULT 0 NOT NULL, lstat text NOT NULL, md5 text NOT NULL, perms text ); ALTER TABLE ONLY file ADD CONSTRAINT file_pkey PRIMARY KEY (fileid); CREATE INDEX file_fp_idx ON file USING btree (filenameid, pathid); CREATE INDEX file_jobid_idx ON file USING btree (jobid); There are 2.7M rows. running update file set perms='0664' took about 10 mins during this period, vmstat reported Blocks Out holding in the 4000 to 6000 range. When I dropped the indexes this query ran in 48sec. Blocks out peaking at 55000. So there is a double whammy. MVCC requires more work to be done when indexes are defined and then this work results in much lower IO, compounding the problem. Comments anyone? --john