Re: join-performance problem

Wolfgang(dot)Fuertbauer(at)ebewe(dot)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