Re: Is this a planner bug?

On 22/04/14 16:45, Tom Lane wrote:
> No. The model is that startup cost is what's expended before the scan can
> start, and then the run cost (total_cost - startup_cost) is expended while
> scanning. Applying a filter increases the run cost and also reduces the
> number of rows returned, but that's got nothing to do with startup cost.
>
> As a comparison point, imagine an index scan that has a filter condition
> in addition to the indexable condition (which let's assume selects
> multiple rows). The startup cost for such a plan corresponds to the index
> descent costs. The run cost corresponds to scanning the index entries
> matching the indexable condition, fetching the heap rows, and applying the
> filter condition.
>
> Or in other words, time to get the first result row is not just startup
> cost; it's startup cost plus run_cost/N, if the plan is estimated to
> return N rows altogether.

Ok, I understand that's the way the model is.

The point is that especially in presence of a "LIMIT 1" there is a
difference between a seq scan that has to fetch a few 10MB to find the
first and only row and an index scan that has to process perhaps a few
kb. And in this case even setting random_page_cost=seq_page_cost didn't
help.

If that query were part of a larger one, I wouldn't want to fiddle with
the cost parameters to get one part of the query fast only to sacrifice
performance in another part.

Torsten