On 22 Sep 2004, Greg Stark wrote:
> Actually this looks like it's arguably a bug to me. Why does the hash
> join execute the sequential scan at all? Shouldn't it also like the
> merge join recognize that the other hashed relation is empty and skip
> the sequential scan entirely?
I'm not sure you can classify that as a bug. It's just that he in one of
the plans started with the empty scan and bacause of that didn't need
the other, but with the hash join it started with the table that had 16
rows and then got to the empty one.
While I havn't checked, I assume that if it had started with the empty
table there then it would have skipped the other.
I don't know what criteria is used to select which part to start with when
doing a hash join. Looks like it started with the one that had the highest
estimate of rows here, doing it the other way around might be a good idea
because you in some cases are lucky to find an empty scans and can omit
the other.
The above are just observations of the behaviour, I've not seen the source
at all.
--
/Dennis Björklund
