X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id AB1CE528B8
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Sat,  6 Aug 2005 02:04:20 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 57096-05
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Sat,  6 Aug 2005 05:04:10 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 18A1E52A38
	for <pgsql-performance@postgresql.org>;
	Sat,  6 Aug 2005 02:04:09 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7653pPB015426;
	Sat, 6 Aug 2005 01:03:51 -0400 (EDT)
To: Rhett Garber <rhettg@gmail.com>
Cc: =?ISO-8859-1?Q?Havasv=F6lgyi_Ott=F3?= <h.otto@freemail.hu>,
	pgsql-performance@postgresql.org
Subject: Re: Why hash join instead of nested loop? 
In-reply-to: <41b0fe8905080516164464e04f@mail.gmail.com> 
References: <41b0fe890508051135712a086b@mail.gmail.com>
	<001801c59a0a$f4be7480$9a00a8c0@OTTO>
	<41b0fe8905080516164464e04f@mail.gmail.com>
Comments: In-reply-to Rhett Garber <rhettg@gmail.com>
	message dated "Fri, 05 Aug 2005 16:16:51 -0700"
Date: Sat, 06 Aug 2005 01:03:51 -0400
Message-ID: <15425.1123304631@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200508/53
X-Sequence-Number: 13800

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