Thread: seq scan startup cost

Imho the simplification, that seq scan startup cost is 0.0 is
only valid when we expect to return most of the rows.

When expecting only 1 row, imho the costs need to be 50 % for
startup and 50 % rest. Assuming, that on average the row will be 
in the middle of that relation file.
When returning 10% of the rows startup would be 10 % ...

The reasoning beeing, that you need to read a few pages before you 
find the first match. 

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Imho the simplification, that seq scan startup cost is 0.0 is
> only valid when we expect to return most of the rows.

> When expecting only 1 row, imho the costs need to be 50 % for
> startup and 50 % rest.

This is already accounted for in the code that makes use of the
estimates.  "Startup cost" is really the time before we can start trying
to produce output, not the time till the first tuple is returned.

An example of the usage is this fragment from costsize.c:
   if (subplan->sublink->subLinkType == EXISTS_SUBLINK)   {       /* we only need to fetch 1 tuple */       subcost =
plan->startup_cost+           (plan->total_cost - plan->startup_cost) / plan->plan_rows;   }
 

If a single row is expected, then this will estimate the actual cost to
fetch it as equal to total_cost, not startup_cost.

It's true that for a seqscan we might reasonably hope to find the wanted
row after scanning only half the file, but what of plans like Aggregate?
The startup/total-cost model isn't sufficiently detailed to capture this
difference, so I prefer to stick with the more conservative behavior.
        regards, tom lane