Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 2BE50632769 for ; Fri, 9 Jul 2010 20:20:03 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 93249-06 for ; Fri, 9 Jul 2010 23:19:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 05E1E632541 for ; Fri, 9 Jul 2010 20:19:55 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o69NJoNJ002742; Fri, 9 Jul 2010 19:19:51 -0400 (EDT) To: Jeremy Palmer cc: "pgsql-performance@postgresql.org" Subject: Re: Index usage with functions in where condition In-reply-to: <666FB8D75E95AE42965A0E76A5E5337E065C035C1E@prdlsmmsg01.ad.linz.govt.nz> References: <666FB8D75E95AE42965A0E76A5E5337E065C035C1E@prdlsmmsg01.ad.linz.govt.nz> Comments: In-reply-to Jeremy Palmer message dated "Sat, 10 Jul 2010 10:36:15 +1200" Date: Fri, 09 Jul 2010 19:19:50 -0400 Message-ID: <2741.1278717590@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201007/164 X-Sequence-Number: 39553 Jeremy Palmer writes: > This is the query that does not use the indexes: > SELECT > coo.nod_id, > 6400000*radians(sqrt((coo.value1 - -41.0618)^2+((coo.value2 - 175.58461)*cos(radians(-41.0618)))^2)) as distance > FROM > crs_coordinate coo > WHERE > coo.value1 between -41.0618-degrees(1200.0/6400000.0) and -41.0618+degrees(1200.0/6400000.0) and > coo.value2 between 175.58461-degrees(1200.0/6400000.0)/(cos(radians(-41.0618))) and 175.58461+degrees(1200.0/6400000.0)/(cos(radians(-41.0618))); Those expressions yield float8, not numeric, and numeric vs float8 isn't an indexable operator for reasons we needn't get into here. You should probably rethink whether numeric is really the best choice of datatype for your columns, if this is the sort of value you expect to work with --- you're paying a considerable price in speed and space for perhaps-illusory precision gains. But if you insist on using numeric then the solution is to cast the expression results to numeric explicitly. BTW I wonder whether you ought not be looking into postgis rather than rolling-your-own coordinate arithmetic ... regards, tom lane