Joseph Shraibman <jks@selectacast.net> writes:
> Well the total cost should be at least as big as the sub-costs, no?
Not if the sub-plan in question is for an EXISTS. The sub-plan cost
is stated in terms of cost to retrieve all rows --- but the outer level
EXISTS isn't going to retrieve all rows, it's going to stop as soon as
it gets even one. So the cost estimate that propagates up is
3035.22/1363.
BTW, this sort of consideration is why 7.0 and later state plan costs
in terms of startup and total cost: if a plan has a nontrivial startup
cost, just dividing total cost by number of tuples isn't a good way to
estimate the costs of partial retrieval. Really the cost estimate is
figured as
startup_cost + (total_cost-startup_cost) * tuples_retrieved/total_tuples.
This is important for EXISTS, LIMIT, and maybe a couple other things.
Without this, we'd not be bright enough to choose fast-startup plans
over least-total-cost plans in cases where fast-startup is what you want.
regards, tom lane