Re: Strange behaviour of SELECT ... IN

uh...

the first one is an INDEX SCAN, the second one a SEQUENTIAL SCAN.

number of rows in table has nothing to do...

any more ideas?

I have been suggested to use an EXPLICIT JOIN instead of the IN statement, but
how do I change the query I have to use join instead of IN?

thnx!

Jorge S.

On Wednesday 26 June 2002 13:40, Stephan Szabo wrote:
> On Wed, 26 Jun 2002, Jorge Sarmiento wrote:
> > when I do a:
> >
> > explain select * from table1 where name in ('JORGE');
> >
> > NOTICE:  QUERY PLAN:
> >
> > Index Scan using idx_table1 on table  (cost=0.00..10901.87 rows=3184
> > width=48)
> >
> > but if do a:
> >
> > explain select * from table1 where name in ('JORGE',  'JUAN',  'JOSE');
> >
> > NOTICE:  QUERY PLAN:
> >
> > Seq Scan on table1  (cost=0.00..16689.73 rows=9506 width=48)
> >
> >
> > why??? is there any way to make postgresql use index in the second type
> > of query?
>
> Well, the number of rows in the second is about 3 times greater.  Have
> you done a vacuum analyze of the table in question?  How many rows does
> the table actually have?
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org