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

Re: 7.4 vs 7.3 ( hash join issue )

From: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: 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 15:22:42
Message-ID: Pine.LNX.4.44.0409221717010.9559-100000@zigo.dhs.org (view raw or flat)
Thread:
Lists: pgsql-patchespgsql-performance
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.

While I havn't checked, I assume that if it had started with the empty 
table there then it would have skipped the other.

I don't know what criteria is used to select which part to start with when
doing a hash join. Looks like it started with the one that had the highest
estimate of rows here, doing it the other way around might be a good idea
because you in some cases are lucky to find an empty scans and can omit
the other.

The above are just observations of the behaviour, I've not seen the source 
at all.

-- 
/Dennis Björklund


In response to

Responses

pgsql-performance by date

Next:From: Greg StarkDate: 2004-09-22 17:38:00
Subject: Re: 7.4 vs 7.3 ( hash join issue )
Previous:From: Greg StarkDate: 2004-09-22 13:43:24
Subject: Re: 7.4 vs 7.3 ( hash join issue )

pgsql-patches by date

Next:From: Szima GáborDate: 2004-09-22 16:17:50
Subject: transaction idle timeout
Previous:From: Greg StarkDate: 2004-09-22 13:43:24
Subject: Re: 7.4 vs 7.3 ( hash join issue )

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