Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-patchespgsql-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

pgsql-performance by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group