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 96B9C9DC84B for ; Thu, 15 Dec 2005 22:26:42 -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 31577-08 for ; Thu, 15 Dec 2005 22:26:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from moonunit2.moonview.localnet (wsip-68-15-5-150.sd.sd.cox.net [68.15.5.150]) by postgresql.org (Postfix) with ESMTP id 4DB329DC820 for ; Thu, 15 Dec 2005 22:26:40 -0400 (AST) Received: from [192.168.0.3] (moonunit3.moonview.localnet [192.168.0.3]) by moonunit2.moonview.localnet (8.13.1/8.13.1) with ESMTP id jBG2QuDL025563 for ; Thu, 15 Dec 2005 18:26:56 -0800 Message-ID: <43A2251A.60907@modgraph-usa.com> Date: Thu, 15 Dec 2005 18:23:22 -0800 From: "Craig A. James" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Overriding the optimizer References: <200512141603.52583.blargity@gmail.com> <7484.1134600423@sss.pgh.pa.us> <1134629567.14248.27.camel@firebolt> <200512150148.16125.blargity@gmail.com> <1134644526.14248.60.camel@firebolt> <43A1C40D.8040006@paradise.net.nz> <43A1F6DB.3080805@modgraph-usa.com> <43A21D74.8030002@familyhealth.com.au> <43A2203B.2050102@familyhealth.com.au> In-Reply-To: <43A2203B.2050102@familyhealth.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.032 required=5 tests=[AWL=0.032] X-Spam-Score: 0.032 X-Spam-Level: X-Archive-Number: 200512/369 X-Sequence-Number: 16190 Christopher Kings-Lynne wrote: >>>> select * from my_table where row_num >= 50000 and row_num < >>>> 100000 >>>> and myfunc(foo, bar); >>> >>> >>> You just create an index on myfunc(foo, bar) >> >> >> only if myfunc(foo, bar) is immutable... > > > And if it's not then the best any database can do is to index scan > row_num - so still you have no problem. Boy, you picked a *really* bad example ;-) The problem is that Postgres decided to filter on myfunc() *first*, and then filter on row_num, resulting in a query time that jumped from seconds to hours. And there's no way for me to tell Postgres not to do that! So, "you still have no problem" is exactly wrong, because Postgres picked the wrong plan. Postgres decided that applying myfunc() to 10,000,000 rows was a better plan than an index scan of 50,000 row_nums. So I'm screwed. Craig