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 9CA689DC806 for ; Sat, 11 Feb 2006 15:48:16 -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 87619-01 for ; Sat, 11 Feb 2006 15:48:16 -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 82E1C9DC80E for ; Sat, 11 Feb 2006 15:48:14 -0400 (AST) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id 0CF1123FBDD for ; Sat, 11 Feb 2006 11:48:15 -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 k1BJmEW4078171 for ; Sat, 11 Feb 2006 11:48:14 -0800 (PST) (envelope-from bryce1@obviously.com) Message-ID: <43EE3F77.6020108@obviously.com> Date: Sat, 11 Feb 2006 11:48:07 -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 Subject: Re: Very slow updates when using IN syntax subselect References: <43ECFF0B.80905@obviously.com> <1682.1139607176@sss.pgh.pa.us> <43ED723E.9080305@obviously.com> <7972.1139672862@sss.pgh.pa.us> In-Reply-To: <7972.1139672862@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.112 required=5 tests=[AWL=0.112] X-Spam-Score: 0.112 X-Spam-Level: X-Archive-Number: 200602/124 X-Sequence-Number: 24134 Tom Lane wrote: > Bryce Nesbitt writes: > >> Tom Lane wrote: >> >>> What does EXPLAIN show for this and for the base query? >>> > > >> -> Seq Scan on event (cost=0.00..0.00 rows=1 width=408) >> Filter: (reconciled = false) >> > > >> select count(*) from event; >> ----------- >> 116226 >> > > It seems pretty clear that you've never vacuumed nor analyzed these > tables ... else the planner would have some clue about their sizes. > Do that and then see what you get. > They occur in fine time. That's good, thanks. But jeeze, can't postgres figure this out for itself?