From: | "Arthur Ward" <award(at)dominionsciences(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Union+group by planner estimates way off? |
Date: | 2003-11-13 19:19:07 |
Message-ID: | 50572.68.62.129.152.1068751147.squirrel@award.gotdns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Manley | 2003-11-13 19:35:58 | Re: strange estimate for number of rows |
Previous Message | Tom Lane | 2003-11-13 18:56:26 | Re: strange estimate for number of rows |