Re: 7.4 vs 7.3 ( hash join issue )

Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:

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

No, postgres didn't do things in reverse order. It hashed the empty table and
then went ahead and checked every record of the non-empty table against the
empty hash table.

Reading the code there's no check for this, and it seems like it would be a
useful low-cost little optimization.

I think postgres normally hashes the table it thinks is smaller, so you do
join against an empty relation it should end up on the hash side of the hash
join and allow postgres to avoid the scan of the outer table.

--
greg