Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id A7EC59FB3FC for ; Fri, 6 Oct 2006 02:24:05 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 84724-08 for ; Fri, 6 Oct 2006 02:23:48 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id AA78F9FB40F for ; Fri, 6 Oct 2006 02:23:46 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from webmail.enterprisedb.com (webmail.enterprisedb.com [63.246.7.176]) by svr4.postgresql.org (Postfix) with ESMTP id 0105A5AF8AD for ; Fri, 6 Oct 2006 05:23:45 +0000 (GMT) Received: from [192.168.42.113] (natpool.bovine.net [67.100.216.14]) by webmail.enterprisedb.com (Postfix) with ESMTP id F1338A24CFF; Fri, 6 Oct 2006 00:23:44 -0500 (CDT) In-Reply-To: References: <20060929153557.GD90915@nasby.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: pgsql-performance@postgresql.org Content-Transfer-Encoding: 7bit From: Jim Nasby Subject: Re: any hope for my big query? Date: Thu, 5 Oct 2006 23:02:57 -0500 To: Ben X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.049 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200610/130 X-Sequence-Number: 21259 On Oct 4, 2006, at 4:40 PM, Ben wrote: > I'm surprised (though probably just because I'm ignorant) that it > would have so much sequential scanning in there. For instance, > because n is going to have at most a couple dozen rows, it seems > that instead of scanning all of public.track, it should be able to > convert my "t.length between a and b" clause to some between > statements or'd together. Or at least, it would be nice if the > planner could do that. That would require the planner having that knowledge at plan-time, which it can't without actually querying the database. One thing that might work wonders is performing the n query ahead of time and then sticking it in an array... that might speed things up. Worst case, you could run the n query, and then run the rest of the query for each row of n you get back. Better yet... send us a patch that allows the planner to look into what a subselect will return to us. ;) -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) -- Jim Nasby jimn@enterprisedb.com EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)