Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id AC4359FB9E7 for ; Fri, 25 May 2007 19:38:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 28182-07 for ; Fri, 25 May 2007 19:38:46 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-254.commandprompt.net [207.173.203.254]) by postgresql.org (Postfix) with ESMTP id 923519FB577 for ; Fri, 25 May 2007 19:38:46 -0300 (ADT) Received: from perhan.alvh.no-ip.org (201-221-217-243.bk12-dsl.surnet.cl [201.221.217.243]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id l4PMcXxC025587; Fri, 25 May 2007 15:38:34 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id A86E532A14; Fri, 25 May 2007 18:38:28 -0400 (CLT) Date: Fri, 25 May 2007 18:38:28 -0400 From: Alvaro Herrera To: Michal Szymanski Cc: Tom Lane , pgsql-performance@postgresql.org Subject: Re: Big problem with sql update operation Message-ID: <20070525223828.GE24789@alvh.no-ip.org> References: <4656A4E0.7020400@datera.pl> <8751.1180103318@sss.pgh.pa.us> <465762B6.3080608@datera.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <465762B6.3080608@datera.pl> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.88.5, clamav-milter version 0.88.5 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Fri, 25 May 2007 15:38:35 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/544 X-Sequence-Number: 24934 Michal Szymanski wrote: > Tom Lane wrote: > >(For the record, the reason you see nonlinear degradation is the > >accumulation of tentatively-dead versions of the row, each of which has > >to be rechecked by each later update.) > > > There is another strange thing. We have two versions of our test > environment one with production DB copy and second genereated with > minimal data set and it is odd that update presented above on copy of > production is executing 170ms but on small DB it executing 6s !!!! How are you vacuuming the tables? -- Alvaro Herrera http://www.advogato.org/person/alvherre "El conflicto es el camino real hacia la unión"