Re: sequence scan, but indexed tables
| От | Tom Lane | 
|---|---|
| Тема | Re: sequence scan, but indexed tables | 
| Дата | |
| Msg-id | 12366.1027086806@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | sequence scan, but indexed tables (csernazs@freemail.hu (Cserna Zsolt)) | 
| Список | pgsql-general | 
csernazs@freemail.hu (Cserna Zsolt) writes:
> explain SELECT picmain.aid from picmain, picalbum where
> picmain.aid=picalbum.aid;
> NOTICE:  QUERY PLAN:
> Hash Join  (cost=806.71..69631.60 rows=832629 width=8)
>   ->  Seq Scan on picalbum  (cost=0.00..14323.29 rows=832629 width=4)
>   ->  Hash  (cost=730.57..730.57 rows=30457 width=4)
>         ->  Seq Scan on picmain  (cost=0.00..730.57 rows=30457
> width=4)
> Both table has "relative" many rows (picmain: around 30000, picalbum:
> around 800000).
Then I'd say the planner is making the right decision.
If you want to experiment, see what plans (and actual runtimes) you get
after turning off enable_hashjoin and/or enable_mergejoin.  With both
off you will get a nestloop with inner indexscan ... and I bet you won't
like it.
> I have postgresql 7.0.3 running on Debian GNU/Linux i386.
You do realize that version is quite ancient?
            regards, tom lane
		
	В списке pgsql-general по дате отправления: