Arthur Ward <award@dominionsciences.com> writes:
> The problem for us is that the default estimate at the HashAggregate is
> absurdly low, undercutting the other available join candidates' row
> estimates resulting in _bad_ plans. What I was wondering is whether the
> planner has enough information available when looking at the
> HashAggregate step (the IN clause that started this whole mess) to
> consider the statistics of the inputs to the Append.
Not at the moment ... UNION (and other set-operation nodes) are pretty
much terra incognita to the planner's estimation routines. If you feel
motivated to work on it, step right up ...
> Additionally, those subquery scans are simple queries without anything
> to cause the table statistics to be thrown away if they can be reused in
> later steps (or is the rowcount the only stat used after a node is
> created?) -- one subquery is a single-table filter, the other is a two
> table join, also nothing special.
The rowcount does propagate up just fine, but guesstimates about numbers
of distinct values don't know anything about these structures. Right
offhand I'm not sure what a suitable framework for handling this would
look like.
regards, tom lane
