Re: Bug #4284

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David Rowley" <dgrowley(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug #4284
Date: 2009-02-10 22:30:04
Message-ID: 25688.1234305004@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David Rowley" <dgrowley(at)gmail(dot)com> writes:
> My report contained a full re-creation script to reproduce the problem and
> tonight I'm having the same problem with CVS Head. To my untrained eye it
> looks like the planner is not properly pushing down the row count.

It looks more like a multicolumn selectivity issue to me. The planner
is supposing that the join condition

ON t1.productiondate = t2.productiondate AND t1.lineid = t2.lineid
AND t1.partcode = t2.partcode

is going to eliminate some fair-size fraction of t1 rows, whereas in
fact the construction of t2 is such that it won't eliminate any of them.
This is less obviously true for the join to t4, but I imagine from the
rowcounts that it's also true there. So you get an unreasonably small
rowcount for whichever join gets done first, and then the nestloop plan
looks like a good idea for the second join.

regards, tom lane

In response to

  • Bug #4284 at 2009-02-10 21:26:35 from David Rowley

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-10 22:36:26 Re: The testing of multi-batch hash joins with skewed data sets patch
Previous Message Robert Haas 2009-02-10 22:23:04 Re: Optimization rules for semi and anti joins