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