Re: Optimizing Query

On Mon, Mar 05, 2001 at 04:59:47PM -0500, Justin Long allegedly wrote:
> Ok, now I have another question... it doesn't seem to be accessing the index.
> 
> explain select k.kbid,k.title from knowledge k , kbwords w0 , kbwords w1 
> WHERE ((k.kbid=w0.kbid and w0.wordid=42743) AND (k.kbid=w1.kbid and 
> w1.wordid=85369))
> 
> NOTICE:  QUERY PLAN:
> 
> Merge Join  (cost=32339.30..35496.97 rows=19262538 width=24)
>    ->  Merge Join  (cost=16530.24..16668.77 rows=233274 width=20)
>          ->  Sort  (cost=15809.06..15809.06 rows=8257 width=4)
>                ->  Seq Scan on kbwords w1  (cost=0.00..15271.85 rows=8257 
> width=4)
>          ->  Sort  (cost=721.18..721.18 rows=2825 width=16)
>                ->  Seq Scan on knowledge k  (cost=0.00..559.25 rows=2825 
> width=16)
>    ->  Sort  (cost=15809.06..15809.06 rows=8257 width=4)
>          ->  Seq Scan on kbwords w0  (cost=0.00..15271.85 rows=8257 width=4)
> 
> Note the sequential scans... there is a wordindex where w0.wordid=42743... 
> why isn't it doing an indexscan? wouldn't that be more efficient?
> 
> Justin

Did you run the 'vacuum analyze' command on the tables concerned (or even
better, the whole database)? Without the data this analysis provides psql
cannot come up with a good execution plan and falls back to full table
scans. Do a 'vacuum analyze' one a week to keep performance levels up.

Cheers,

Mathijs
-- 
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.                                                   Erik Naggum