Re: [PERFORM] LIKE should use index when condition doesn't include wildcard

[Tom Lane]

Palle Girgensohn <[EMAIL PROTECTED]> writes:
> Shouldn't the optimizer use indices if the like condition does not have any 
> wildcards?

I can't get excited about this; if you are depending on LIKE to be fast
then you should have locale-insensitive indexes in place to support it.
Switching the tests around so that this special case is supported even
with an index that doesn't otherwise support LIKE would complicate the
code unduly IMHO, to support a rather pointless corner case...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[PERFORM] LIKE should use index when condition doesn't include wildcard

[Palle Girgensohn]

Hi,

Shouldn't the optimizer use indices if the like condition does not have any 
wildcards?

An example:

girgen=# explain analyze select * from person where userid = 'girgen';
QUERY PLAN 

---
--
Index Scan using person_pkey on person  (cost=0.00..5.98 rows=1 width=84) 
(actual time=0.034..0.039 rows=1 loops=1)
  Index Cond: (userid = 'girgen'::text)
Total runtime: 0.091 ms
(3 rader)

girgen=# explain analyze select * from person where userid like 'girgen';
   QUERY PLAN 

---
---
Seq Scan on person  (cost=0.00..77.08 rows=1 width=84) (actual 
time=1.137..1.143 rows=1 loops=1)
  Filter: (userid ~~ 'girgen'::text)
Total runtime: 1.193 ms
(3 rader)

The result cannot be different between the two cases. The second query does 
not use the index since database is initiaized with a locale, 
sv_SE.ISO8859-1, and I need it for correct sorting. (Still dreaming about 
indices with like and locale)... But, since there is no wildcard in the 
string 'girgen', it should easily be able to use the index, if it only 
bothered to note that there is a wildcard around, right?

Another thing on the same subject:

I use an app that builds searches using some standard method, and it wants 
to always search case-insensitive. Hence, it uses ILIKE instead of `=', 
even for joins, and even for integers. This is a bit lazy, indeed, and also 
wrong. While this is wrong, no doubt,  the odd thing I realized was that 
the optimizer didn't make use of the indices. Same thing here, the 
optimizer should ideally know that it is dealing with integers, where ILIKE 
and LIKE has no meaning, and it should use `=' instead implicitally, hence 
using indices. This one might be kind of low priority, but the one above 
really isn't, IMO.

/Palle

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]