>>>>> "Konstantin" == Konstantin Knizhnik <k.knizh...@postgrespro.ru> writes:
>> No, startup cost is not the "time to find the first row". It's >> overhead paid before you even get to start examining rows. Konstantin> But it seems to me that calculation of cost in LIMIT node Konstantin> contradicts with this statement: The model (assuming I understand it rightly) is that what we're actually tracking is a startup cost and a per-output-row cost, but for comparison purposes we actually store the rows and the computed total, rather than just the per-row cost: rows startup_cost total_cost = startup_cost + (rows * per_row_cost) So what Limit is doing the for the offset count is recovering the subpath's per_row_cost from (total_cost - startup_cost)/rows, and then scaling that by the number of rows in the offset (which are being discarded), and adding that to the startup cost. So this is saying: the startup cost for OFFSET N is the startup cost of the subplan, plus the cost of fetching N rows from the subplan. (And after fetching those N rows, we still haven't found the first row that we will actually return.) For LIMIT N, we instead replace the old total cost with a new one calculated from the startup cost plus N times the subplan's per-row cost. -- Andrew (irc:RhodiumToad)
