From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EXPLAIN ANALYZE output weird for Top-N Sort |
Date: | 2014-11-14 02:00:44 |
Message-ID: | 29990.1415930444@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2014-11-14 02:03:57 | Re: what does this mean: "running xacts with xcnt == 0" |
Previous Message | David Rowley | 2014-11-14 01:51:32 | Re: using custom scan nodes to prototype parallel sequential scan |