webmaster <webmaster@tony.cz> writes:
> explain select catnum.catnum, kat.ident, kat.nazev where
> catnum.catnum=kat.ident;
> resulting as:
> HASH JOIN ...
> -> SEQ SCAN ON catnum ...
> -> HASH ...
> -> SEQ SCAN ON kat...
> So, I can see that it's performing two scans without using indexes. Why?
Looks like a perfectly reasonable plan to me. The nice thing about a
hash join is that it doesn't need to examine the tables in sorted order,
so there's no need for the expense of an index scan. The system tries
to estimate whether this will be cheaper than a merge join (which does
need to scan the tables in sorted order), and evidently it thinks so.
You haven't given us nearly enough info to tell whether that's a good
decision or not, however. How big are the tables, and what are the data
types of the columns you're joining on? It would help also to see the
*full* output from EXPLAIN, including all the numeric values.
regards, tom lane