Re: seq scan over 3.3 million rows instead of single key index access - Mailing list pgsql-performance

Gregory,

>  I would suggest running ANALYZE
> idtellUued at some point before the problematic query.

Thank you.
After adding analyze all is OK.
Is analyze command required in  8.3 also ?
Or is it better better to specify some hint at create temp table time since
I know the number of rows before running query ?

Andrus.

set search_path to firma2,public;
 CREATE TEMP TABLE idtellUued(dokumnr INT) ON COMMIT DROP;
 INSERT INTO idtellUued VALUES(1249228);
analyze idtelluued;
 explain analyze  select 1
   from dok JOIN rid USING(dokumnr)
 JOIN idtellUued USING(dokumnr)

"Nested Loop  (cost=0.00..275.18 rows=3 width=0) (actual time=87.266..87.388
rows=8 loops=1)"
"  ->  Nested Loop  (cost=0.00..6.95 rows=1 width=8) (actual
time=36.613..36.636 rows=1 loops=1)"
"        ->  Seq Scan on idtelluued  (cost=0.00..1.01 rows=1 width=4)
(actual time=0.009..0.015 rows=1 loops=1)"
"        ->  Index Scan using dok_dokumnr_idx on dok  (cost=0.00..5.93
rows=1 width=4) (actual time=36.585..36.590 rows=1 loops=1)"
"              Index Cond: (dok.dokumnr = "outer".dokumnr)"
"  ->  Index Scan using rid_dokumnr_idx on rid  (cost=0.00..267.23 rows=80
width=4) (actual time=50.635..50.672 rows=8 loops=1)"
"        Index Cond: ("outer".dokumnr = rid.dokumnr)"
"Total runtime: 87.586 ms"