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 5B5CB11F6553 for ; Tue, 28 Mar 2006 21:30:28 -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 53555-04 for ; Tue, 28 Mar 2006 21:30:27 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from globalrelay.com (mail1.globalrelay.com [216.18.71.77]) by postgresql.org (Postfix) with ESMTP id 3279611F654D for ; Tue, 28 Mar 2006 21:30:24 -0400 (AST) X-Virus-Scanned: Scanned by GRC-AntiVirus Gateway X-GR-Acctd: YES Received: from [216.160.41.114] (HELO DaveEMachine) by globalrelay.com (CommuniGate Pro SMTP 4.2.3) with ESMTP id 86737710; Tue, 28 Mar 2006 17:30:23 -0800 From: "Dave Dutcher" To: "'Steinar H. Gunderson'" , Subject: Re: simple join uses indexes, very slow Date: Tue, 28 Mar 2006 19:30:23 -0600 Message-ID: <010a01c652d0$59ccd870$8300a8c0@tridecap.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20060328173442.GA31836@uio.no> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.111 required=5 tests=[AWL=0.111] X-Spam-Score: 0.111 X-Spam-Level: X-Archive-Number: 200603/569 X-Sequence-Number: 18006 > -----Original Message----- > From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance- > owner@postgresql.org] On Behalf Of Steinar H. Gunderson > 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. I was just looking this over again and I realized I misread the query plan. The slowest step was the Bitmap Heap Scan not the sort. (The sort was relatively fast.)