On 2/5/2012 20:34, Tom Lane wrote:
On reflection I think that the idea of clamping ndistinct beforehand is
just wrong, and what we ought to do instead is apply a multiplier to the
selectivity estimate afterwards. In the case of a base rel we could
just multiply by the selectivity of its baserestrictinfo list. For join
rels it's a bit harder to guess how much a given input relation might
have been decimated, but if the join's estimated size is smaller than
the output size of the base rel the correlation var came from, we could
multiply by that ratio (on top of whatever correction came from the base
rel's restriction clauses).
I got stuck in some cases where (due to a tree of filters) the planner
underestimates the JOIN just because the ndistinct conveys a huge number
to the selectivity estimation formula. However, the estimation of both
input relations is made correctly and is limited.
I've tried to understand the logic through commits 0d3b231eebf,
97930cf578e and 7f3eba30c9d. But it is still not clear.
So, why the idea of clamping ndistinct is terrible in general? Could you
explain your reasons a bit more?
--
regards,
Andrey Lepikhov
Postgres Professional
