Re: Why hash join instead of nested loop?

This is postgres 7.4.1

All the rows involved are integers.

Thanks,

Rhett

On 8/5/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Rhett Garber <rhettg@gmail.com> writes:
> > Hash Join  (cost=5.96..7.04 rows=1 width=14) (actual
> > time=10.591..10.609 rows=1 loops=1)
> >    Hash Cond: ("outer".id = "inner".obj2)
> >    ->  Seq Scan on rtmessagestate  (cost=0.00..1.05 rows=5 width=14)
> > (actual time=0.011..0.022 rows=5 loops=1)
> >    ->  Hash  (cost=5.96..5.96 rows=1 width=4) (actual
> > time=0.109..0.109 rows=0 loops=1)
> >          ->  Index Scan using connection_regid_obj1_index on
> > connection  (cost=0.00..5.96 rows=1 width=4) (actual time=0.070..0.076
> > rows=1 loops=1)
> >                Index Cond: ((connection_registry_id = 40105) AND (obj1
> > = 73582)) Total runtime: 11.536 ms
> > (7 rows)
>
> [ scratches head... ]  If the hash table build takes only 0.109 msec
> and loads only one row into the hash table, and the scan of
> rtmessagestate takes only 0.022 msec and produces only 5 rows, it is
> real hard to see how the join takes 10.609 msec overall.  Unless the id
> and obj2 columns are of a datatype with an incredibly slow equality
> function.  What is the datatype involved here, anyway?  And what PG
> version are we speaking of?
>
>                         regards, tom lane
>