Actually the query is created like this. User enters the query in a user interface. User can type any character in the query criteria. ie. % and _ can be at any place. User have the freedom to choose query columns as well. The query is agianst a single table .
rgds Antony Paul On Tue, 25 Jan 2005 19:49:12 +1100, Russell Smith <[EMAIL PROTECTED]> wrote: > On Tue, 25 Jan 2005 07:23 pm, Antony Paul wrote: > > Creating an index and using lower(column) does not change the explain > > plan estimates. > > It seems that it is not using index for like or ilike queries > > irrespective of whether it have a pattern matching character in it or > > not. (using PostgreSQL 7.3.3) > > > > On googling I found this thread > > > > http://archives.postgresql.org/pgsql-sql/2004-11/msg00285.php > > > > It says that index is not used if the search string begins with a % symbol. > > What exactly are the type of like queries you are going? there is a solution > for having the % at the start, but you can win everyway. > > > > > rgds > > Antony Paul > > > > On Mon, 24 Jan 2005 20:58:54 +1100, Russell Smith <[EMAIL PROTECTED]> wrote: > > > On Mon, 24 Jan 2005 08:18 pm, Antony Paul wrote: > > > > Hi, > > > > I have a query which is executed using ilike. The query values are > > > > received from user and it is executed using PreparedStatement. > > > > Currently all queries are executed as it is using iilike irrespective > > > > of whether it have a pattern matching character or not. Can using = > > > > instead of ilike boot performance ?. If creating index can help then > > > > how the index should be created on lower case or uppercase ?. > > > > > > > It depends on the type of queries you are doing. > > > > > > changing it to something like lower(column) like lower('text%'), and > > > creating an index on lower(column) will give you much better performance. > > > > > > If you have % in the middle of the query, it will still be slow, but I > > > assume that is not > > > the general case. > > > > > > I am not sure what the effect of it being prepared will be, however I've > > > had much success > > > with the method above without the queries being prepared. Others may be > > > able to offer advice > > > about if prepare will effect it. > > > > > > Regards > > > > > > Russell Smith > > > > > > > > ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq