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