Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U6NGp-0003iN-US for pgsql-performance@arkaria.postgresql.org; Fri, 15 Feb 2013 15:32:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1U6NGp-0003cX-CW for pgsql-performance@arkaria.postgresql.org; Fri, 15 Feb 2013 15:32:15 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U6NGn-0003bS-Uy for pgsql-performance@postgresql.org; Fri, 15 Feb 2013 15:32:14 +0000 Received: from adsl-static64.rox.net ([213.214.18.64]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U6NGm-0000jR-DE for pgsql-performance@postgresql.org; Fri, 15 Feb 2013 15:32:13 +0000 Received: from zimbra.office.aycan.de (zimbra.office.aycan.de [192.168.255.28]) by adsl-static64.rox.net (Postfix) with ESMTP id 87FEF577C4; Fri, 15 Feb 2013 16:32:11 +0100 (CET) Received: from [192.168.254.100] (fsc.office.aycan.de [192.168.254.100]) by zimbra.office.aycan.de (Postfix) with ESMTPSA id 794263805E0BD; Fri, 15 Feb 2013 16:32:11 +0100 (CET) Message-ID: <511E54FA.8010107@aycan.de> Date: Fri, 15 Feb 2013 16:32:10 +0100 From: =?ISO-8859-1?Q?Florian_Schr=F6ck?= Organization: aycan Digitalsysteme GmbH User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Kevin Grittner CC: "pgsql-performance@postgresql.org" Subject: Re: Very slow update statement on 40mio rows References: <511E469F.70308@aycan.de> <1360940357.13532.YahooMailNeo@web162905.mail.bf1.yahoo.com> In-Reply-To: <1360940357.13532.YahooMailNeo@web162905.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hello Kevin, not updating every row which doesn't need the update solved the problem! Your query took only 1 minute. :) Thank you so much for the fast response, have a great weekend! PS: When you switch to "TEXT" on the explain URL you can see the final runtime which was 66 minutes with the original statement. Best regards, Florian On 02/15/2013 03:59 PM, Kevin Grittner wrote: > Florian Schr=F6ck wrote: > >> UPDATE BackupFiles >> SET nTapeNr=3D0, nAFIOCounter=3D0, nBlockCounter=3D0, >> cStatus=3D'NEW'::StatusT, bOnSetBlue=3Dfalse, >> bOnSetYellow=3Dfalse, nLastBackupTS=3D '0001-01-01 00:00:00' >> WHERE cStatus=3D'NEW' OR cStatus=3D'WRITING' OR cStatus=3D'ONTAPE'; >> >> Explain analyze: http://explain.depesz.com/s/8y5 >> The statement takes 60-90 minutes. > The EXPLAIN ANALYZE at that URL shows a runtime of 3 minutes and 41 > seconds. > >> I tried to optimize the settings but until now without success. >> >> Can we optimize this update statement somehow? Do you have any >> other ideas? > Are there any rows which would already have the values that you are > setting? If so, it would be faster to skip those by using this > query: > > UPDATE BackupFiles > SET nTapeNr=3D0, nAFIOCounter=3D0, nBlockCounter=3D0, > cStatus=3D'NEW'::StatusT, bOnSetBlue=3Dfalse, > bOnSetYellow=3Dfalse, nLastBackupTS=3D '0001-01-01 00:00:00' > WHERE (cStatus=3D'NEW' OR cStatus=3D'WRITING' OR cStatus=3D'ONTAPE') > AND (nTapeNr <> 0 OR nAFIOCounter <> 0 OR nBlockCounter <> 0 > OR cStatus <> 'NEW'::StatusT > OR bOnSetBlue IS DISTINCT FROM false > OR bOnSetYellow IS DISTINCT FROM false > OR nLastBackupTS <> '0001-01-01 00:00:00'); > > Another way to accomplish this is with the > suppress_redundant_updates_trigger() trigger function: > > http://www.postgresql.org/docs/9.2/interactive/functions-trigger.html > --=20 Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance