Re: No hash join across partitioned tables?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: No hash join across partitioned tables?
Date: 2009-04-19 23:31:51
Message-ID: 12401.1240183911@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Kris Jurka <books(at)ejurka(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-04-20 00:44:56 Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Previous Message Tom Lane 2009-04-19 22:38:33 Re: [PATCH] Borland C Compiler compatibility issues

Browse pgsql-performance by date

  From Date Subject
Next Message Rafael Domiciano 2009-04-20 13:55:36 SQL With Dates
Previous Message Grzegorz Jaśkiewicz 2009-04-18 12:02:08 Re: stats are way off on 8.4 b1