X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id F06D652958 for ; Wed, 22 Jun 2005 16:25:22 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 93316-05 for ; Wed, 22 Jun 2005 19:25:21 +0000 (GMT) Received: from matlab.pharmadm.com (derma.pharmadm.com [193.190.169.32]) by svr1.postgresql.org (Postfix) with ESMTP id 6960F52939 for ; Wed, 22 Jun 2005 16:25:20 -0300 (ADT) Received: from [192.168.93.22] (matlab.pharmadm.com [192.168.93.22]) by matlab.pharmadm.com (Postfix) with ESMTP id 4540DBCE5 for ; Wed, 22 Jun 2005 21:25:21 +0200 (CEST) Message-ID: <42B9BB20.7050109@student.kuleuven.ac.be> Date: Wed, 22 Jun 2005 21:25:20 +0200 From: Kurt De Grave User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: parameterized LIKE does not use index Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200506/443 X-Sequence-Number: 13080 Hi, Consider the where-clauses: WHERE lower(col) LIKE 'abc'; WHERE lower(col) LIKE 'abc%'; these will both use a b-tree functional index in lower(col) if one exists. The clause WHERE lower(col) LIKE '%abc'; can't use the index as you would expect, because of the wildcard at the front. Thus, it has to do a seqscan, on what in my case is a very large table. But still that's not too bad, because I expect an overwhelming amount of the simple cases, and only very few that start with a percentage sign. Now, what's problematic is if I replace the literal with a parameter, like this: WHERE lower(col) LIKE ? It seems that the parameterized query gets compiled once, and because the parameter is not yet known, one cannot be sure it doesn't start with a percentage sign. Using the parameterized version causes ALL cases to use a seqscan. Of course, I could modify the application and send different SQL depending on which case we're in or just constructing a query with a literal each time, but is there a way to add a hint to the SQL that would cause the query to be re-planned if it's a case that could use the index? Or can I convince the (Perl) driver to do so? kurt.