Re: 7.4 vs 7.3 ( hash join issue )

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
Subject: Re: 7.4 vs 7.3 ( hash join issue )
Date: 2004-09-22 17:56:34
Message-ID: 14106.1095875794@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:
> 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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Greg Stark 2004-09-22 18:46:12 Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )
Previous Message Greg Stark 2004-09-22 17:56:13 Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Stark 2004-09-22 18:46:12 Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )
Previous Message Greg Stark 2004-09-22 17:56:13 Re: [PERFORM] 7.4 vs 7.3 ( hash join issue )