Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 210B96501EA for ; Wed, 12 Nov 2008 20:20:25 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 50487-01 for ; Wed, 12 Nov 2008 20:20:09 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gransy.com (unknown [82.208.29.208]) by mail.postgresql.org (Postfix) with ESMTP id E588E6502B5 for ; Wed, 12 Nov 2008 20:20:08 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by mail.gransy.com (Postfix) with ESMTP id 0D0897AC006 for ; Thu, 13 Nov 2008 01:20:07 +0100 (CET) Received: from mail.gransy.com ([127.0.0.1]) by localhost (nathalia.gransy.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMfEE0GiLwXt for ; Thu, 13 Nov 2008 01:20:06 +0100 (CET) Received: from [192.168.1.1] (ip-89-102-139-23.karneval.cz [89.102.139.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTP id DC6187AC04C for ; Thu, 13 Nov 2008 01:20:06 +0100 (CET) Message-ID: <491B72BB.6000703@fuzzy.cz> Date: Thu, 13 Nov 2008 01:20:11 +0100 From: Tomas Vondra User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 CC: pgsql-performance@postgresql.org Subject: Re: slow full table update References: <200811101729.14977@centrum.cz> <200811101730.11057@centrum.cz> <200811101730.15902@centrum.cz> <61593.89.102.139.23.1226335300.squirrel@sq.gransy.com> <200811121725.30238@centrum.cz> <63509.89.102.139.23.1226508479.squirrel@sq.gransy.com> <200811121825.26487@centrum.cz> <491B1653.3040600@archonet.com> <20663.1226523248@sss.pgh.pa.us> In-Reply-To: <20663.1226523248@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.681 tagged_above=0 required=5 tests=MISSING_HEADERS=1.581, RDNS_NONE=0.1 X-Spam-Level: * X-Archive-Number: 200811/116 X-Sequence-Number: 31847 > The explain plan tree only shows the time to fetch/compute the new rows, > not to actually perform the update, update indexes, or fire triggers. > If there is a big discrepancy then the extra time must be going into > one of those steps. > > 8.1 does show trigger execution time separately, so the most obvious > problem (unindexed foreign key reference) seems to be excluded, unless > the OP just snipped that part of the output ... Yeah, that quite frequent problem with updates. Try to separate create a copy of the table, i.e. CREATE TABLE test_table AS SELECT * FROM table; and try to execute the query on it. What tables do reference the original table using a foreign key? Do they have indexes on the foreign key column? How large are there referencing tables? Are these tables updated heavily and vacuumed properly (i.e. aren't they bloated with dead rows)? I'm not sure if the FK constraints are checked always, or just in case the referenced column is updated. I guess the FK check is performed only in case of DELETE or when the value in the FK column is modified (but update of the primary key is not very frequent I guess). Are there any triggers and / or rules on the table? regards Tomas