Re: seq scan over 3.3 million rows instead of single key index access

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"