Re: [PERFORM] 7.4 vs 7.3 ( hash join issue ) - Mailing list pgsql-patches

From Tom Lane
Subject Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )
Date
Msg-id 17291.1095879635@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )  (Greg Stark <gsstark@mit.edu>)
List pgsql-patches
Greg Stark <gsstark@mit.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

pgsql-patches by date:

Previous
From: Greg Stark
Date:
Subject: Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )
Next
From: Alvaro Herrera
Date:
Subject: ALTER TABLE .. OWNER TO and sequences