Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>,Gaetano Mendola <mendola(at)bigfoot(dot)com>,pgsql-performance(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )
Date: 2004-09-22 19:00:35
Message-ID: 17291.1095879635@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patchespgsql-performance
Greg Stark <gsstark(at)mit(dot)edu> writes:
>> It would also be interesting to prefetch one row from the outer table and fall
>> out immediately (without building the hash table) if the outer table is
>> empty.  This seems to require some contortion of the code though :-(

> Why is it any more complicated than just moving the hash build down lower?

Having to inject the consideration into ExecHashJoinOuterGetTuple seems
messy to me.

On reflection I'm not sure it would be a win anyway, for a couple of reasons.
(1) Assuming that the planner has gotten things right and put the larger
relation on the outside, the case of an empty outer relation and a
nonempty inner one should rarely arise.
(2) Doing this would lose some of the benefit from the optimization to
detect an empty inner relation.  If the outer subplan is a slow-start
one (such as another hashjoin), it would lose a lot of the benefit :-(

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Scott KirkwoodDate: 2004-09-22 19:50:26
Subject: Caching of Queries
Previous:From: Greg StarkDate: 2004-09-22 18:46:12
Subject: Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-09-22 19:14:27
Subject: ALTER TABLE .. OWNER TO and sequences
Previous:From: Greg StarkDate: 2004-09-22 18:46:12
Subject: Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group