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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches pgsql-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

Browse pgsql-patches by date

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

Browse pgsql-performance by date

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