X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id BBB67D1DCC0 for ; Fri, 16 Apr 2004 11:40:02 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 40456-07 for ; Fri, 16 Apr 2004 11:39:55 -0300 (ADT) Received: from MP-NY01.horizonk.com (mp-ny01.horizonk.com [208.51.57.221]) by svr1.postgresql.org (Postfix) with SMTP id 36D90D1D391 for ; Fri, 16 Apr 2004 11:39:53 -0300 (ADT) Received: from hklog ([192.168.69.176]) by hk-nysrv01.horizonk.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 10:39:56 -0400 Subject: Re: Update is very slow on a bigger table From: Dimitar Georgievski To: Tom Lane Cc: pgsql-sql@postgresql.org In-Reply-To: <21949.1082069503@sss.pgh.pa.us> References: <200404151507.RAA03297@rodos> <1082063227.5415.217.camel@hklog> <21949.1082069503@sss.pgh.pa.us> Content-Type: text/plain Organization: Horizon Knwoledge Message-Id: <1082126436.12136.46.camel@hklog> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 16 Apr 2004 10:40:36 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2004 14:39:56.0234 (UTC) FILETIME=[AFBD7AA0:01C423C0] X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200404/146 X-Sequence-Number: 17521 Tom, Yes. it looks like there was some locking condition in the database. in the meantime it disappeared and the updates run quickly. thanks for your help. this is the first time i'm working with PostgreSQL and wasn't sure where to look for possible causes of the problem. thanks, dimitar On Thu, 2004-04-15 at 18:51, Tom Lane wrote: > Dimitar Georgievski writes: > > the process under which the update is running reports among the usual > > process data "UPDATE waiting". > > I don't think the UPDATE is doing anything at all --- that ps output > implies that it's waiting for some other backend to release an exclusive > lock on the table, or an update lock on one of the rows to be updated. > > The pg_locks view might help you determine who's the culprit. > > regards, tom lane