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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
