Re: join-performance problem

Wolfgang.Fuertbauer@ebewe.com writes:
> Hash Join  (cost=482.82..704.62 rows=80 width=93)
>   ->  Hash Join  (cost=481.78..702.17 rows=80 width=79)
>         ->  Hash Join  (cost=480.44..699.43 rows=80 width=59)
>               ->  Seq Scan on artikel c  (cost=0.00..155.77 rows=4977
> width=18)
>               ->  Hash  (cost=480.24..480.24 rows=80 width=41)
>                     ->  Nested Loop  (cost=0.00..480.24 rows=80 width=41)
>                           ->  Index Scan using fakt_kunde_key on fakt b
> (cost=0.00..55.11 rows=13 width=16)
>                           ->  Index Scan using faktzeilen_pkey on
> faktzeilen a  (cost=0.00..31.82 rows=10 width=25)
>         ->  Hash  (cost=1.27..1.27 rows=27 width=20)
>               ->  Seq Scan on argruppen e  (cost=0.00..1.27 rows=27
> width=20)
>   ->  Hash  (cost=1.03..1.03 rows=3 width=14)
>         ->  Seq Scan on kollektion d  (cost=0.00..1.03 rows=3 width=14)

> can you pleas explain me why c is now scanned sequential?

Looks like a reasonable choice to me.  80 indexscan probes would
probably cost more than the one seqscan, given that c is so small.

The alternative of putting c on the inside of the hashjoin won't
be chosen as long as c is the larger relation...
        regards, tom lane