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]
