Re: exists

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