Re: EXPLAIN ANALYZE output weird for Top-N Sort

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

In response to

Browse pgsql-hackers by date

  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