Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 61F609FCB90 for ; Thu, 8 Nov 2007 18:51:27 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 59575-05 for ; Thu, 8 Nov 2007 18:51:24 -0400 (AST) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by postgresql.org (Postfix) with ESMTP id AF3DD9FCB8C for ; Thu, 8 Nov 2007 18:51:23 -0400 (AST) Received: from trofast.ipv6.sesse.net ([2001:700:300:1803:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IqGDY-00019U-Tk; Thu, 08 Nov 2007 23:51:21 +0100 Received: from root by trofast.sesse.net with local (Exim 4.68) (envelope-from ) id 1IqGDY-0005yr-AM; Thu, 08 Nov 2007 23:51:20 +0100 Date: Thu, 8 Nov 2007 23:51:20 +0100 From: "Steinar H. Gunderson" To: Pepe Barbe Cc: pgsql-performance@postgresql.org Subject: Re: Join performance Message-ID: <20071108225120.GA22963@uio.no> Mail-Followup-To: Pepe Barbe , pgsql-performance@postgresql.org References: <2ACEBABD-7853-475B-B8C0-91B654AF143D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2ACEBABD-7853-475B-B8C0-91B654AF143D@gmail.com> X-Operating-System: Linux 2.6.20.4 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/116 X-Sequence-Number: 27531 On Thu, Nov 08, 2007 at 04:47:09PM -0600, Pepe Barbe wrote: > I am having an issue on PostgreSQL 8.0.12. In the past we had performance > issues with the query planner for queries on some tables where we knew we > had indexes and it was doing a sequential scan, and for this reason we > issue "SET enable_seqscan = FALSE" for some queries. This is a bad idea in general. Did you really measure that this made queries run faster? Generally, using an index is not always a win, and the planner tries to figure out when it isn't. Setting it globally is seldom a good idea anyway; if it really _is_ a win for a given query, you could always set it locally in that session. > Any ideas what could I try to fix this problem? Re-enable seqscan? /* Steinar */ -- Homepage: http://www.sesse.net/