From: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EXPLAIN ANALYZE output weird for Top-N Sort |
Date: | 2014-11-14 01:50:24 |
Message-ID: | 1415929823999-5826938.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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...raising the thought
that the "actual" row count should not be 10 but should equal whatever the
input row count size is.
I guess there may be some efficient algorithms and/or inputs that make a
sort go slower or faster but ultimately the node would have to ensure that
every input row has been sorted before it can return control to its parent
node. If the parent only cares about the first 10 rows of the now-sorted
relation the sort node doesn't know or care.
David J.
--
View this message in context: http://postgresql.nabble.com/EXPLAIN-ANALYZE-output-weird-for-Top-N-Sort-tp5826922p5826938.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2014-11-14 01:51:32 | Re: using custom scan nodes to prototype parallel sequential scan |
Previous Message | Tom Lane | 2014-11-14 01:48:26 | Re: EXPLAIN ANALYZE output weird for Top-N Sort |