Thread: Seq scan with a like operator

Seq scan with a like operator

From
"Jouneau Luc"
Date:
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),
  ....
) WITH OIDS;
CREATE INDEX personne_fk3
  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'
 
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
-------
select nom_int
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
 
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

Re: Seq scan with a like operator

From
Peter Eisentraut
Date:
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/

Re: Seq scan with a like operator

From
"Jouneau Luc"
Date:
> 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


Re: Seq scan with a like operator

From
Peter Eisentraut
Date:
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/