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 D8CB6DAF89 for ; Wed, 26 Oct 2005 18:37:27 -0300 (ADT) 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 05207-01 for ; Wed, 26 Oct 2005 21:37:24 +0000 (GMT) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id 41D36DAF7B for ; Wed, 26 Oct 2005 18:37:25 -0300 (ADT) Received: from trofast.ipv6.sesse.net ([2001:700:300:dc03:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1EUsxZ-0006My-Ax for pgsql-performance@postgresql.org; Wed, 26 Oct 2005 23:37:26 +0200 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1EUsxe-0000gS-00 for ; Wed, 26 Oct 2005 23:37:30 +0200 Date: Wed, 26 Oct 2005 23:37:30 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: Materializing a sequential scan Message-ID: <20051026213730.GA2295@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <20051019174544.GA32303@samfundet.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20051019174544.GA32303@samfundet.no> X-Operating-System: Linux 2.6.14-rc5 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.01 required=5 tests=[AWL=0.010] X-Spam-Level: X-Archive-Number: 200510/397 X-Sequence-Number: 15165 Hi, I finally found what I believe is the root cause for the hopeless performance, after a lot of query rewriting: > Subquery Scan mdb_effektiv_tilgang (cost=19821.69..4920621.69 rows=10000 width=48) > Filter: ((NOT (hashed subplan)) AND (NOT (subplan))) The problem here is simply that 8.1 refuses to hash this part of the plan: > -> Materialize (cost=546.45..742.37 rows=19592 width=38) > -> Seq Scan on rita_tilgang (cost=0.00..526.86 rows=19592 width=38) > -> Seq Scan on personer_nylig_slettet (cost=0.00..31.40 rows=2140 width=4) probably because of the NOT IN with a function inside; I rewrote it to an EXCEPT (which is not equivalent, but good enough for my use), and it instantly hashed the other subplan, and the query went speedily. Well, at least in four seconds and not several hours... Any good ideas why 8.1 would refuse to do this, when 7.4 would do it? It does not matter how high I set my work_mem; even at 2.000.000 it refused to hash the subplan. /* Steinar */ -- Homepage: http://www.sesse.net/