From: | Joseph Shraibman <jks(at)selectacast(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-sql <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: exists |
Date: | 2001-08-21 20:51:00 |
Message-ID: | 3B82C9B4.4000200@selectacast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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(at)selectacast(dot)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(at)selectacast(dot)net
Increase signal to noise ratio. http://www.targabot.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-08-21 21:03:42 | Re: exists |
Previous Message | Tom Lane | 2001-08-21 20:44:28 | Re: Should I worry? |