From: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
---|---|
To: | "Pavel Velikhov" <pvelikhov(at)yahoo(dot)com> |
Cc: | "Kenneth Marshall" <ktm(at)rice(dot)edu>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: need help with a query |
Date: | 2007-10-21 16:44:01 |
Message-ID: | 36e682920710210944m4ba6b073yde7ef284aa7e1d74@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 10/20/07, Pavel Velikhov <pvelikhov(at)yahoo(dot)com> 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(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Lee Keel | 2007-10-22 16:10:11 | Memory Settings.... |
Previous Message | Erik Jones | 2007-10-20 22:02:23 | Re: [SQL] two queryes in a single tablescan |