Then why does the explain say rows=1363 ?
I don't mean to nitpick here, but maybe this is the symptom of a larger problem.
Tom Lane wrote:
> 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
>
--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio. http://www.targabot.com
