Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 0CD379FB229 for ; Mon, 15 Jan 2007 17:46:33 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 04269-06 for ; Mon, 15 Jan 2007 17:45:52 -0400 (AST) X-Greylist: delayed 00:19:39.222538 by SQLgrey-1.7.4 Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id D2CE89FB26A for ; Mon, 15 Jan 2007 17:45:52 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from mail.brownpapertickets.com (mail.brownpapertickets.com [66.235.70.236]) by svr4.postgresql.org (Postfix) with ESMTP id 08BDF5AF8FF for ; Mon, 15 Jan 2007 21:26:13 +0000 (GMT) Received: from flashheart.brownpapertickets.com (edmund.pandimensional.org [216.231.37.50] (may be forged)) (authenticated bits=0) by mail.brownpapertickets.com (8.13.6/8.12.8) with ESMTP id l0FLPrHd018659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Jan 2007 13:25:54 -0800 Message-Id: <7.0.1.0.2.20070115124931.06433838@pandimensional.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 15 Jan 2007 13:26:04 -0800 To: pgsql-sql@postgresql.org From: William Scott Jordan Subject: Referencing tables are grinding UPDATE to a halt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.136 tagged_above=0 required=5 tests=BAYES_50, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200701/50 X-Sequence-Number: 27202 Hey all! I'm having some trouble with a simple update on a table that only has about 250,000 rows in it. The table itself looks something like: CREATE TABLE price_details ( price_detail_id int PRIMARY KEY, private bool ) ; There is one table that references price_details, but isn't affected by the "private" column, and one table that references this second table. They look something like: CREATE TABLE prices ( p_id int PRIMARY KEY, price_detail_id int NOT NULL REFERENCES price_details ON DELETE CASCADE, max_sales int ) ; CREATE INDEX prices_price_detail_id ON prices (price_detail_id) ; CREATE TABLE sales ( sales_id int PRIMARY KEY, p_id int NOT NULL REFERENCES prices ON DELETE CASCADE, sales int ) ; CREATE INDEX sales_p_id ON sales (p_id) ; I'm trying to do a simple update to the "private" column in the price_details table, which I expected to take a few seconds at most. After 10 minutes, I gave up and ran explain, with this as the result: EXPLAIN UPDATE price_details SET private = 't' WHERE private = 'f' ; ---------------------------------------------------------------------------------------- Nested Loop (cost=2663.45..363527947.70 rows=118759098 width=50) Join Filter: (subplan) -> Seq Scan on sales (cost=0.00..3685.27 rows=54627 width=42) -> Materialize (cost=2663.45..2706.93 rows=4348 width=12) -> Seq Scan on price_details (cost=0.00..2663.45 rows=4348 width=12) Filter: (private = false) SubPlan -> Index Scan using prices_price_detail_id on prices (cost=0.00..3.01 rows=1 width=4) Index Cond: (price_detail_id = $0) Seq Scan on price_details (cost=0.00..2663.45 rows=4348 width=508) Filter: (private = false) (12 rows) ---------------------------------------------------------------------------------------- So it looks to me like the postgres is checking this table against the table that references it, and the table that reference that table, making what should be a very easy transaction into something unusable. Is there any way to avoid this without losing proper referencing? Any suggestions would be appreciated. -Scott