=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= <torsten.foertsch@xxxxxxx> writes: > What I'm asking is the following. Assuming node without any filter has a > startup cost C1, a total cost of C2 and produces N rows. Now, a filter > is applied which passes through M rows. Then the startup cost for the > node *with* the filter applied should be different from C1 because a > certain amount of rows from the beginning is filtered out, right? 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. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
