Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 93E429FBC40 for ; Tue, 29 May 2007 17:41:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 45052-06 for ; Tue, 29 May 2007 17:41:43 -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 C474C9FBC08 for ; Tue, 29 May 2007 17:41:45 -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 l4TKfTen003780; Tue, 29 May 2007 13:41:34 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 0746A32A16; Tue, 29 May 2007 16:41:25 -0400 (CLT) Date: Tue, 29 May 2007 16:41:25 -0400 From: Alvaro Herrera To: Michal Szymanski Cc: Michal Szymanski , Tom Lane , pgsql-performance@postgresql.org Subject: Re: Big problem with sql update operation Message-ID: <20070529204124.GG11630@alvh.no-ip.org> References: <4656A4E0.7020400@datera.pl> <8751.1180103318@sss.pgh.pa.us> <465762B6.3080608@datera.pl> <20070525223828.GE24789@alvh.no-ip.org> <4659BB70.7070200@gdfi.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4659BB70.7070200@gdfi.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]); Tue, 29 May 2007 13:41:40 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/586 X-Sequence-Number: 24976 Michal Szymanski wrote: > 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? > > > Using pgAdmin (DB is installed on my laptop) and I use this tool for > vaccuminh, I do not think that vaccuming can help because I've tested on > both database just after importing. I think you are misunderstanding the importance of vacuuming the table. Try this: on a different terminal from the one running the test, run a VACUUM on the updated table with vacuum_cost_delay set to 20, on an infinite loop. Keep this running while you do your update test. Vary the vacuum_cost_delay and measure the average/min/max UPDATE times. Also try putting a short sleep on the infinite VACUUM loop and see how its length affects the UPDATE times. One thing not clear to me is if your table is in a clean state. Before running this test, do a TRUNCATE and import the data again. This will get rid of any dead space that may be hurting your measurements. -- Alvaro Herrera http://www.advogato.org/person/alvherre "The Postgresql hackers have what I call a "NASA space shot" mentality. Quite refreshing in a world of "weekend drag racer" developers." (Scott Marlowe)