Re: Very Very Wierd

Martijn van Oosterhout <kleptog@svana.org>

From: Martijn van Oosterhout <kleptog@svana.org>
To: Varun Kacholia <varunk@cse.iitb.ac.in>
Cc: Postgresql General <pgsql-general@postgresql.org>
Date: 2002-06-18T23:21:19Z
Lists: pgsql-general
On Wed, Jun 19, 2002 at 01:24:28AM +0530, Varun Kacholia wrote:
>  hi ,
>    Now i think something has happened wrong to the db that after doing
>    vaccum analyze, it has started behaving very very weirdly.
>    
>    suryadb=# explain SELECT * FROM dbmedia WHERE ID IN ((SELECT id FROM wdmedia WHERE word = 'boyzone') )  LIMIT 200;
>    NOTICE:  QUERY PLAN:
>    Limit  (cost=0.00..1005445.27 rows=200 width=76)
>      ->  Seq Scan on dbmedia  (cost=0.00..507161673.46 rows=100883 width=76)
> 	     ^^^^^^^^^^^    
> 			 SubPlan
> 			           ->  Materialize  (cost=5027.19..5027.19 rows=2575 width=4)
> 					                   ->  Index Scan using wdkmedia on wdmedia  (cost=0.00..5027.19 rows=2575 width=4)
> 					
>  why the hell cant it recognise that ID is a primary field and it has
>  just to do an index lookup? and also seeing at the time which is taken 
>  to execute the query i am damn sure that entire table scan is done.
>  it takes abt 30 secs to finish it (Athlon XP 1.7 gigs, 128 MB DDR).
>  And i think that this is terrible.Also it is not that the word is too
>  frequent that it chooses to do a sequential scan than an indexed one .
>  Should i build up an index also on ID so that it recognises it?
>  or is there a flaw in postgresql that queries with 'IN' are not
>  looked up from index but sequentially scanned?

Look up the FAQ. Use EXISTS, not IN. No-one has shown to satisfaction when
an IN can be converted to the equivalent EXISTS.

-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.