Thread: Seq scan with a like operator
Hi,
I don't understand why with a like operator, PostgreSQL 7.4.2 does not behave the same as with an equal operator :
Here's a table with about 200.000 tuples :
CREATE TABLE public.annu_pers2
(
nom varchar(50),
prenom varchar(50),
nom_int varchar(50),
....
(
nom varchar(50),
prenom varchar(50),
nom_int varchar(50),
....
) WITH OIDS;
CREATE INDEX personne_fk3
ON public.annu_pers2
USING btree
(nom_int);
ON public.annu_pers2
USING btree
(nom_int);
======
Here are the two explain analyze requests :
select nom_int
from annu_pers2
where nom_int ='X'
from annu_pers2
where nom_int ='X'
Index Scan using personne_fk3 on annu_pers2 (cost=0.00..125.66 rows=31 width=11) (actual time=0.359..0.359 rows=0 loops=1)
Index Cond: ((nom_int)::text = 'X'::text)
Total runtime: 0.490 ms
Index Cond: ((nom_int)::text = 'X'::text)
Total runtime: 0.490 ms
-------
select nom_int
from annu_pers2
where nom_int like 'X'
from annu_pers2
where nom_int like 'X'
Seq Scan on annu_pers2 (cost=0.00..5885.60 rows=31 width=11) (actual time=1213.594..1213.594 rows=0 loops=1)
Filter: ((nom_int)::text ~~ 'X'::text)
Total runtime: 1213.729 ms
Filter: ((nom_int)::text ~~ 'X'::text)
Total runtime: 1213.729 ms
Could someone give me a reason of the sequential scan on the request with like operator
(I know that without % a like operator is not usefull, but it was to restrain as much as possible probability of mistakes - the problem remains the same with or without %).
Thanks for your answer(s).
Luc
Am Freitag, 23. Juli 2004 14:50 schrieb Jouneau Luc: > I don't understand why with a like operator, PostgreSQL 7.4.2 does not > behave the same as with an equal operator : LIKE requires a different kind of index. See <http://www.postgresql.org/docs/7.4/static/indexes-opclass.html>. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> LIKE requires a different kind of index. See > <http://www.postgresql.org/docs/7.4/static/indexes-opclass.html>. Thanks for the answer peter, I didn't notice it when I red the doc, but if I create the index as specified then it is the query with equal operator which use a seq scan. Do I have to create 2 indexes on the same column (with different datatype) in order to support different kind of queries ? Well, It seems quite strange to me : Suppose you have an user interface in which user can parameter his query on 4 varchar fields (independantly, i.e field 4 does not need to have field 1,2 or 3 filled), and you allow to use generic character such as '*' or '?' (which will be translated into '%' and '_'). User can also fill in exact values. Then you would have to create 4*2=8 indexes to handle every combinations of possible queries. It would also mean that support both exact generic queries double the indexing task on update/insert/delete. Am I wrong ? Luc Jouneau
Am Freitag, 23. Juli 2004 17:24 schrieb Jouneau Luc: > I didn't notice it when I red the doc, but if I create the index as > specified then it is the query with equal operator which use a seq scan. > Do I have to create 2 indexes on the same column (with different datatype) > in order to support different kind of queries ? Yes. > Well, It seems quite strange to me : > Suppose you have an user interface in which user can parameter his query on > 4 varchar fields (independantly, i.e field 4 does not need to have field > 1,2 or 3 filled), and you allow to use generic character such as '*' or '?' > (which will be translated into '%' and '_'). User can also fill in exact > values. I think that kind of interface would use the LIKE operator no matter whether the user entered wildcards or not. > It would also mean that support both exact generic queries double the > indexing task on update/insert/delete. Well, if you want to optimize lots of different queries, the system needs to provide lots of different support. -- Peter Eisentraut http://developer.postgresql.org/~petere/