Re: Why hash join instead of nested loop?

From: Tom Lane
Subject: Re: Why hash join instead of nested loop?
Date: ,
Msg-id: 15425.1123304631@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Why hash join instead of nested loop?  (Rhett Garber)
Responses: Re: Why hash join instead of nested loop?  (Rhett Garber)
List: pgsql-performance

Tree view

Why hash join instead of nested loop?  (Rhett Garber, )
 Re: Why hash join instead of nested loop?  (Havasvölgyi Ottó, )
  Re: Why hash join instead of nested loop?  (Rhett Garber, )
   Re: Why hash join instead of nested loop?  (Tom Lane, )
    Re: Why hash join instead of nested loop?  (Rhett Garber, )
     Re: Why hash join instead of nested loop?  (Tom Lane, )
      Re: Why hash join instead of nested loop?  ("Steinar H. Gunderson", )
      Re: Why hash join instead of nested loop?  (Michael Fuhr, )
      Re: Why hash join instead of nested loop?  (Ian Westmacott, )
       Re: Why hash join instead of nested loop?  (Tom Lane, )
        Re: Why hash join instead of nested loop?  (Ian Westmacott, )
      Re: Why hash join instead of nested loop?  (Rhett Garber, )
       Re: Why hash join instead of nested loop?  (Tom Lane, )
        Re: Why hash join instead of nested loop?  (Rhett Garber, )
         Re: Why hash join instead of nested loop?  (Tom Lane, )
          Re: Why hash join instead of nested loop?  (Rhett Garber, )
           Re: Why hash join instead of nested loop?  (Tom Lane, )
            Re: Why hash join instead of nested loop?  (Rhett Garber, )

Rhett Garber <> 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


pgsql-performance by date:

From: Tom Lane
Date:
Subject: Re: Why hash join instead of nested loop?
From: Patrick Hatcher
Date:
Subject: Slow update statement