Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id A73969F9C08 for ; Sun, 21 Oct 2007 13:44:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 80409-02 for ; Sun, 21 Oct 2007 13:44:03 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by postgresql.org (Postfix) with ESMTP id 5A9CB9F9B6C for ; Sun, 21 Oct 2007 13:44:03 -0300 (ADT) Received: by rv-out-0910.google.com with SMTP id l15so825737rvb for ; Sun, 21 Oct 2007 09:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wAAnLpbpl6PdFyI6xgBiixwCHMQA1l9jwYIpj01Knkc=; b=FZhVsu/YubIKe/EXYO8mTSnqYe/P/UeCEmMXyluWgOZ9HaGsm2nmYzbAsQo2ojABv/JCsE0hzHBLiuSSxE/baHu0zEwkhl/IzAmKrZ7gUMtcPGaDNo1dtnvCj3Jk1sasmDjjf/L+JyELl4a98OH+Nn/a5uIB+hSjLtCzl8+XLOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CiE7mWkTRVNoHGo5DGUNPaftkSYz2RWgumrNKv9juxLKcOtTPeJB+ccFoWX37DGsU6LXuwmtah3dNctLhpByE5L/C1m0AFKlAZD1pTCT3egHZ9qc6ptMGa2Utg4Dk27GRh3ALpYTRIi/nvwLopE4gdZa7+GFKjYDHLExND0SJZU= Received: by 10.143.157.10 with SMTP id j10mr1065772wfo.1192985041864; Sun, 21 Oct 2007 09:44:01 -0700 (PDT) Received: by 10.143.19.7 with HTTP; Sun, 21 Oct 2007 09:44:01 -0700 (PDT) Message-ID: <36e682920710210944m4ba6b073yde7ef284aa7e1d74@mail.gmail.com> Date: Sun, 21 Oct 2007 12:44:01 -0400 From: "Jonah H. Harris" To: "Pavel Velikhov" Subject: Re: need help with a query Cc: "Kenneth Marshall" , pgsql-performance@postgresql.org In-Reply-To: <639622.45761.qm@web56412.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <639622.45761.qm@web56412.mail.re3.yahoo.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/239 X-Sequence-Number: 27261 On 10/20/07, Pavel Velikhov wrote: > Left the query running for 10+ hours and had to kill it. I guess there > really was no need to have lots of > shared buffers (the hope was that postgresql will cache the whole table). I > ended up doing this step inside > the application as a pre-processing step. Can't have postgres running with > different fsych options since this > will be part of an "easy to install and run" app, that should just require a > typical PosgreSQL installation. Is the size always different? If not, you could limit the updates: UPDATE links SET target_size = size FROM articles WHERE articles.article_id = links.article_to AND links.target_size != articles.size; Since this is a huge operation, what about trying: CREATE TABLE links_new AS SELECT l.col1, l.col2, a.size as target_size, l.col4, ... FROM links l, articles a WHERE a.article_id = l.article_to; Then truncate links, copy the data from links_new. Alternatively, you could drop links, rename links_new to links, and recreate the constraints. I guess the real question is application design. Why doesn't this app store size at runtime instead of having to batch this huge update? -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/