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
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 ) |
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 ) |