X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id BC6C8DB78D for ; Mon, 14 Nov 2005 20:28:20 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 56452-05 for ; Tue, 15 Nov 2005 00:28:17 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noao.edu (noao.edu [140.252.1.54]) by svr1.postgresql.org (Postfix) with ESMTP id E40F2DB774 for ; Mon, 14 Nov 2005 20:28:18 -0400 (AST) X-TFF-CGPSA-Version: 1.4f1 X-TFF-CGPSA-Filter: Scanned Received: from weaver.tuc.noao.edu ([140.252.14.8] verified) by noao.edu (CommuniGate Pro SMTP 5.0.1) with ESMTPS id 21636820; Mon, 14 Nov 2005 17:28:19 -0700 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by weaver.tuc.noao.edu (8.13.1/8.13.1) with ESMTP id jAF0SJc5001260; Mon, 14 Nov 2005 17:28:19 -0700 Message-ID: <43792BA3.3060702@noao.edu> Date: Mon, 14 Nov 2005 17:28:19 -0700 From: Steve Wampler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Postgres-performance Subject: Re: Help speeding up delete References: <43790A99.9050603@noao.edu> <5E90D296-FA4A-4E48-92B4-396AADE35EF2@slamb.org> <43792355.1020501@noao.edu> <38242de90511141610j621d9a02r52a1d6f4fc55cb55@mail.gmail.com> In-Reply-To: <38242de90511141610j621d9a02r52a1d6f4fc55cb55@mail.gmail.com> 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.004 required=5 tests=[AWL=0.004] X-Spam-Score: 0.004 X-Spam-Level: X-Archive-Number: 200511/236 X-Sequence-Number: 15493 Joshua Marsh wrote: > > > On 11/14/05, *Steve Wampler* > wrote: > > However, even that seems to have a much higher cost than I'd expect: > > lab.devel.configdb=# explain delete from "tmp_table2" where id in > (select id from tmp_table2 where name='obsid' and value = > 'oid080505'); > NOTICE: QUERY PLAN: > > Seq Scan on tmp_table2 (cost=0.00..65705177237.26 rows=769844 > width=6) > SubPlan > -> Materialize (cost=42674.32..42674.32 rows=38 width=50) > -> Seq Scan on tmp_table2 (cost=0.00..42674.32 > rows=38 width=50) > > > For one reason or the other, the planner things a sequential scan is the > best solution. Try turning off seq_scan before the query and see if it > changes the plan (set enable_seqscan off;). > > I've seen this problem with sub queries and that usually solves it. > Hmmm, not only does it still use sequential scans, it thinks it'll take even longer: set enable_seqscan to off; SET VARIABLE explain delete from "tmp_table2" where id in (select id from tmp_table2 where name='obsid' and value = 'oid080505'); NOTICE: QUERY PLAN: Seq Scan on tmp_table2 (cost=100000000.00..160237039405992.50 rows=800836 width=6) SubPlan -> Materialize (cost=100043604.06..100043604.06 rows=45 width=26) -> Seq Scan on tmp_table2 (cost=100000000.00..100043604.06 rows=45 width=26) EXPLAIN But the advice sounds like it *should* have helped... -- Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud.