On Mon, May 13, 2013 at 4:14 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> The planner is estimating this the outer side of this nested loop will >> produce 33 rows and that the inner side will produce 1. One would >> assume that the row estimate for the join product couldn't be more >> than 33 * 1 = 33 rows, but the planner is estimating 62335 rows, which >> seems like nonsense. > > You know, of course, that the join size estimate isn't arrived at that > way. Still, this point does make it seem more like a planner bug and > less like bad input stats. It would be nice to see a self-contained > example ... Yeah, I remember there have been examples like this that have come up before. Unfortunately, I haven't fully grokked what's actually going on here that allows this kind of thing to happen. Refresh my memory on where the relevant code is? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
