Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I agree we don't want anything that is O(high), but I was thinking of
> something that would be more agressive than 1%, which works well for
> lots of self joins, but I am not sure how well for other cases.
That assumption is without foundation. The particular case we are
looking at in Eric's example has a problem only because there is one
cpu_operator_cost more or less in the estimated startup costs.
I believe that the problem was actually created recently (7.4 or
possibly 7.3) by planner changes that account for expression evaluation
costs more completely than we used to do. This is important when an
expression involves an expensive sub-select, but for typical cases it
simply results in very small deltas between startup costs of
otherwise-similar plans. 1% fuzz is plenty to fix that.
Before asserting that we need more flexibility, please point to some
real cases where it's needed. Your argument depends on numbers pulled
out of the air that don't necessarily have anything to do with the
planner's actual behavior.
> What if instead of doing total cost 1% difference, we compute
> total-per-row + startup being 1% different?
Doesn't seem to me to have useful properties...
regards, tom lane