Re: Strange behaviour of SELECT ... IN - Mailing list pgsql-general

From Jorge Sarmiento
Subject Re: Strange behaviour of SELECT ... IN
Date
Msg-id 200206261600.08523.jsarmiento@ccom.org
Whole thread Raw
In response to Re: Strange behaviour of SELECT ... IN  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Responses Re: Strange behaviour of SELECT ... IN  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Re: Strange behaviour of SELECT ... IN  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
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




pgsql-general by date:

Previous
From: "Glen Parker"
Date:
Subject: Re: unlimited undo/journaling
Next
From: Stephan Szabo
Date:
Subject: Re: Strange behaviour of SELECT ... IN