From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: No hash join across partitioned tables? |
Date: | 2009-04-17 01:02:04 |
Message-ID: | Pine.BSO.4.64.0904162046050.27034@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Thu, 16 Apr 2009, Kris Jurka wrote:
> Perhaps the cost estimates for the real data are so high because of this
> bogus row count that the fudge factor to disable mergejoin isn't enough?
>
Indeed, I get these cost estimates on 8.4b1 with an increased
disable_cost value:
nestloop: 11171206.18
merge: 58377401.39
hash: 116763544.76
So the default disable_cost isn't enough to push it to use the hash join
plan and goes back to nestloop. Since disable_cost hasn't been touched
since January 2000, perhaps it's time to bump that up to match today's
hardware and problem sizes? This isn't even a particularly big problem,
it's joing 18M rows against 30k.
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.
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-04-17 01:43:11 | Re: HashJoin w/option to unique-ify inner rel |
Previous Message | Robert Haas | 2009-04-17 00:28:43 | Re: HashJoin w/option to unique-ify inner rel |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-04-17 01:22:08 | Re: GiST index performance |
Previous Message | Francisco Figueiredo Jr. | 2009-04-16 23:43:20 | Re: need information |