From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Wolfgang(dot)Fuertbauer(at)ebewe(dot)com |
Cc: | pgsql-sql(at)postgresql(dot)org, Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Subject: | Re: join-performance problem |
Date: | 2002-05-02 13:58:12 |
Message-ID: | 7116.1020347892@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | wit | 2002-05-02 15:06:35 | get transaction no. |
Previous Message | Rajesh Kumar Mallah. | 2002-05-02 09:36:49 | Re: Weird select output... |