X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 635D49DCDE5 for ; Tue, 28 Mar 2006 13:34:53 -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 15054-06-4 for ; Tue, 28 Mar 2006 13:34:49 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by postgresql.org (Postfix) with ESMTP id D04D19DD594 for ; Tue, 28 Mar 2006 13:34:47 -0400 (AST) 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 1FOI5d-0003x5-Bg for pgsql-performance@postgresql.org; Tue, 28 Mar 2006 19:34:45 +0200 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1FOI5b-0008Ik-00 for ; Tue, 28 Mar 2006 19:34:43 +0200 Date: Tue, 28 Mar 2006 19:34:43 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: simple join uses indexes, very slow Message-ID: <20060328173442.GA31836@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <20060328162908.GB26539@uio.no> <00da01c6528b$e3b6fd30$8300a8c0@tridecap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00da01c6528b$e3b6fd30$8300a8c0@tridecap.com> X-Operating-System: Linux 2.6.14.3 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.091 required=5 tests=[AWL=0.091] X-Spam-Score: 0.091 X-Spam-Level: X-Archive-Number: 200603/551 X-Sequence-Number: 17988 On Tue, Mar 28, 2006 at 11:20:19AM -0600, Dave Dutcher wrote: > I guess what I am really curious about is why was the OP getting an > expensive sort when the planner tried a merge join? A merge join requires sorted inputs. > Most of the time was spent sorting the parameters parameters table by > opset_num even though opset_num is indexed. Isn't Postgres able to walk the > index instead of sorting? The time of an index scan vs. a sequential scan + sort depends on several factors, so it's not just a matter of walking the index whenever there is one. /* Steinar */ -- Homepage: http://www.sesse.net/