Re: 7.4 vs 7.3 ( hash join issue ) - Mailing list pgsql-performance

From Tom Lane
Subject Re: 7.4 vs 7.3 ( hash join issue )
Date
Msg-id 14106.1095875794@sss.pgh.pa.us
Whole thread Raw
In response to Re: 7.4 vs 7.3 ( hash join issue )  (Greg Stark <gsstark@mit.edu>)
Responses Re: 7.4 vs 7.3 ( hash join issue )  (Greg Stark <gsstark@mit.edu>)
Re: 7.4 vs 7.3 ( hash join issue )  (Gaetano Mendola <mendola@bigfoot.com>)
List pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> 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.

Yeah, I was just looking at doing that.

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 :-(

> I think postgres normally hashes the table it thinks is smaller,

Right, it will prefer to put the physically smaller table (estimated
width*rows) on the inside.

            regards, tom lane

pgsql-performance by date:

Previous
From: Greg Stark
Date:
Subject: Re: 7.4 vs 7.3 ( hash join issue )
Next
From: Greg Stark
Date:
Subject: Re: 7.4 vs 7.3 ( hash join issue )