Date: Thu, 18 Feb 2010 13:43:44 +0100
From: "A. Kretschmer" <andreas.kretschmer@schollglas.com>
To: pgsql-performance@postgresql.org
Subject: Re: index usage in not like
Message-ID: <20100218124344.GH23676@a-kretschmer.de>
References: <2a7905441002180355w6dc89a87y8643c0a7f881072a@mail.gmail.com>
	<bddc86151002180400n920f56ah9fa3d68156c6b24a@mail.gmail.com>
	<20100218121810.GG23676@a-kretschmer.de>
	<20100218122622.GD8639@it.is.rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100218122622.GD8639@it.is.rice.edu>
User-Agent: Mutt/1.5.9i

In response to Kenneth Marshall :
> > > How many rows do you have in your table?  If there are relatively few,
> > > it probably guesses it to be cheaper to do a sequential scan and
> > > calculate lower values on-the-fly rather than bother with the index.
> > 
> > That's one reason, an other reason, i think, is, that a btree-index can't
> > search with an 'not like' - operator.
> 
> The 'not like' condition is likely to be extremely non-selective
> which would cause a sequential scan to be used in any event whether
> or not an index could be used.

That's true, but i have an example where the 'not like' condition is
extremely selective:

,----[  sql  ]
| test=*# select count(1) from words where lower(w) not like lower('f%');
|  count
| -------
|     10
| (1 row)
|
| test=*# select count(1) from words where lower(w)  like lower('f%');
|  count
| -------
|  10000
| (1 row)
`----


But the index can't use:

,----[  code  ]
| test=*# explain select * from words where lower(w) not like lower('f%');
|                         QUERY PLAN
| ----------------------------------------------------------
|  Seq Scan on words  (cost=0.00..4396.15 rows=10 width=47)
|    Filter: (lower(w) !~~ 'f%'::text)
| (2 rows)
`----


And i think, the reason is:

,----[  quote from docu  ]
| B-trees can handle equality and range queries on data that can be sorted
| into some ordering. In particular, the PostgreSQL query planner will
| consider using a B-tree index whenever an indexed column is involved in
| a comparison using one of these operators:
|
| <
| <=
| =
| >=
| >
`----


Regards, Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431  2EB0 389D 1DC2 3172 0C99