Re: EXPLAIN ANALYZE output weird for Top-N Sort - Mailing list pgsql-hackers

From Tom Lane
Subject Re: EXPLAIN ANALYZE output weird for Top-N Sort
Date
Msg-id 29990.1415930444@sss.pgh.pa.us
Whole thread Raw
In response to Re: EXPLAIN ANALYZE output weird for Top-N Sort  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-hackers
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.  

> I don't see how a sort node cannot run to completion...

The sort must have read all of its *input*, or it can't be sure it's
giving the correct first result row.  But "run to completion" means
that it delivered all of its *output*, which obviously does not happen
when under a LIMIT.

It's entirely possible BTW that the sort's internal processing is not
complete when it starts returning rows.  For example, when we do a
spill-to-disk merge sort, the final merge pass is typically done
on-the-fly while returning rows, and so some fraction of that processing
may never be completed if the query stops early.  It's still seen all the
input rows, but it hasn't completely determined their ordering.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: using custom scan nodes to prototype parallel sequential scan
Next
From: Peter Eisentraut
Date:
Subject: Re: what does this mean: "running xacts with xcnt == 0"