David G Johnston <david.g.johnston@gmail.com> writes:
> Tom Lane-2 wrote
>> [ shrug... ] The estimated value is the planner's estimate of what would
>> happen *if you ran the node to completion*, which in practice doesn't
>> happen because of the LIMIT. The actual value is, well, the actual value.
>> We certainly should not munge around the actual value.
>>
>> We could imagine munging the reported estimates to account for the parent
>> LIMIT, but that would make it a lot harder to understand the planner's
>> "thought processes", because the reported estimates would have that much
>> less to do with the numbers actually used in the internal calculations.
> Is it even possible for a sort node directly under a limit to output (as
> nebulous as that term is in this context) more rows that desired by the
> limit?
No. The "actual" rowcount is the number of rows returned by the node,
and since the LIMIT node will stop calling its child for new rows once
it's satisfied, there's no way for more rows to be returned.
> The interesting thing about a sort node is not its output but its input -
> i.e., the number of rows being fed to it via the node nested under it.
Right, which you can read off directly from the EXPLAIN output as being
the actual number of rows output by its child node.
> Which prompts the question whether it would be good to show that value as an
> attribute of the sort node during EXPLAIN ANALYZE instead of having to scan
> down to the child node.
It would not be useful IMO to duplicate the information; EXPLAIN output
tends to be too voluminous already. I suppose somebody could do a
thorough redesign of EXPLAIN's output layout to associate numbers with
different plan levels than they are today ... but I'm less than convinced
that it'd be an improvement.
regards, tom lane