> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
>
> I have thought of a fairly clean way to attack this problem, which
> is to represent the cost of a plan in two parts instead of only one.
> Instead of just "cost", have "startup cost" and "cost per tuple".
> (Actually, it'd probably be easier to work with "startup cost" and
> "total cost if all tuples are retrieved", but that's a trivial
> representational detail; the point is that our cost model will now be
> of the form a*N+b when N tuples are retrieved.) It'd be pretty easy
> to produce plausible numbers for all the plan types we use. Then,
> the plan comparators would keep any plan that wins on either startup
> or total cost, rather than only considering total cost. Finally
> at the top level of planning, when there is a LIMIT the preferred
> plan would be selected by comparing a*LIMIT+b rather than total cost.
>
I have no objection but have a question.
It seems current cost estimation couldn't be converted into a*N+b
form exactly. For example,the cost of seq scan iscount of pages + count of tuples * cpu_weight + ..
count of pages couldn't be converted into a*N form.
The cost of index scan is more complicated.
I thought of no clear way to treat it when I thought about
this item once.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp