X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 81E789DC83D for ; Sat, 11 Feb 2006 01:12:43 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14740-06 for ; Sat, 11 Feb 2006 01:12:42 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from outbound.internet-mail-service.net (outbound6.internet-mail-service.net [216.240.47.197]) by postgresql.org (Postfix) with ESMTP id 80E279DC81A for ; Sat, 11 Feb 2006 01:12:41 -0400 (AST) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id C313423FACB; Fri, 10 Feb 2006 21:12:40 -0800 (PST) Received: from [192.168.1.109] (adsl-69-107-112-198.dsl.pltn13.pacbell.net [69.107.112.198]) by idiom.com (8.12.11/8.12.11) with ESMTP id k1B5CbwU008758; Fri, 10 Feb 2006 21:12:37 -0800 (PST) (envelope-from bryce1@obviously.com) Message-ID: <43ED723E.9080305@obviously.com> Date: Fri, 10 Feb 2006 21:12:30 -0800 From: Bryce Nesbitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-sql@postgresql.org CC: Tom Lane Subject: Re: Very slow updates when using IN syntax subselect References: <43ECFF0B.80905@obviously.com> <1682.1139607176@sss.pgh.pa.us> In-Reply-To: <1682.1139607176@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.111 required=5 tests=[AWL=0.111] X-Spam-Score: 0.111 X-Spam-Level: X-Archive-Number: 200602/122 X-Sequence-Number: 24132 Tom Lane wrote: > Bryce Nesbitt writes: > >> update event set reconciled=true where event_id in >> (select event_id from event join token using (token_number) >> where token_status=50 and reconciled=false LIMIT 1); >> >> On a 4 CPU machine, 2 CPU's peg at 100%, and the request just eats CPU >> forever. >> > What does EXPLAIN show for this and for the base query? QUERY PLAN ------------------------------------------------------------------------------------------- Nested Loop (cost=0.00..3.04 rows=1 width=8) -> Seq Scan on event (cost=0.00..0.00 rows=1 width=408) Filter: (reconciled = false) -> Index Scan using token_token_number_key on token (cost=0.00..3.03 rows=1 width=11) Index Cond: (("outer".token_number)::text = (token.token_number)::text) Filter: (token_status = 50) (6 rows) QUERY PLAN ------------------------------------------------------------------------------------------------- Nested Loop IN Join (cost=0.00..3.06 rows=1 width=616) Join Filter: ("outer".event_id = "inner".event_id) -> Seq Scan on event (cost=0.00..0.00 rows=1 width=616) -> Nested Loop (cost=0.00..3.04 rows=1 width=8) -> Seq Scan on event (cost=0.00..0.00 rows=1 width=408) Filter: (reconciled = false) -> Index Scan using token_token_number_key on token (cost=0.00..3.03 rows=1 width=11) Index Cond: (("outer".token_number)::text = (token.token_number)::text) Filter: (token_status = 50) (9 rows) select count(*) from event; ----------- 116226 stage=# select count(*) from token; ------- 8948