To: Kris Jurka <books@ejurka.com>
cc: pgsql-performance@postgresql.org
Subject: Re: No hash join across partitioned tables? 
In-reply-to: <Pine.BSO.4.64.0904162046050.27034@leary.csoft.net> 
References: <Pine.BSO.4.64.0904161836540.11937@leary.csoft.net>
	<7163.1239923531@sss.pgh.pa.us>
	<Pine.BSO.4.64.0904161921080.11937@leary.csoft.net>
	<Pine.BSO.4.64.0904162046050.27034@leary.csoft.net>
Comments: In-reply-to Kris Jurka <books@ejurka.com>
	message dated "Thu, 16 Apr 2009 21:02:04 -0400"
Date: Sun, 19 Apr 2009 19:31:51 -0400
Message-ID: <12401.1240183911@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kris Jurka <books@ejurka.com> writes:
> The real problem is getting reasonable stats to pass through the partition 
> Append step, so it can make a reasonable estimate of the join output size.

I dug around a bit and concluded that the lack of stats for the Append
relation is indeed the main problem.  It's not so much the bad join size
estimate (although that could hurt for cases where you need to join this
result to another table).  Rather, it's that the planner is deliberately
biased against picking hash joins in the absence of stats for the inner
relation.  Per the comments for estimate_hash_bucketsize:

 * If no statistics are available, use a default estimate of 0.1.  This will
 * discourage use of a hash rather strongly if the inner relation is large,
 * which is what we want.  We do not want to hash unless we know that the
 * inner rel is well-dispersed (or the alternatives seem much worse).

While we could back off the default a bit here, I think it'd be better
to fix it by not punting on the stats-for-append-relations problem.
That doesn't seem like material for 8.4 at this point, though.

			regards, tom lane