> In this particular case the inaccurate estimate doesn't matter too much, > I think, although it might be encouraging the system to select hash > aggregation since it thinks the hashtable will be pretty small. If the > estimate were getting used to plan higher-up plan steps then it could > be a bigger problem.
That's my problem; this is a subselect feeding in to a larger query. That wrong estimate causes the planner to select a nested-loop at the next step up. At 83,000 rows, the word is "ouch!" At any rate, I discovered this while dissecting a giant & slow query. Hence, while disabling nested-loop joins avoids this particular pitfall, it's not good for the bigger picture. I think I'm going to end up splitting this larger query into smaller parts and reassemble the pieces in the application so I can push some smarts past other subselect boundaries. For my purposes, that should skirt the issue of union+group estimates not being calculated. As always, thanks for the fast answers! ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html