From: | Jeremy Harris <jgh(at)wizmail(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EXPLAIN ANALYZE output weird for Top-N Sort |
Date: | 2014-11-14 20:27:01 |
Message-ID: | 54666595.60901@wizmail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/11/14 14:54, Tom Lane wrote:
> Jeremy Harris <jgh(at)wizmail(dot)org> writes:
>> On 14/11/14 00:46, Simon Riggs wrote:
>>> Limit (cost=.... rows=20 width=175) (actual time=.... rows=20 loops=1)
>>> -> Sort (cost=.... rows=568733 width=175) (actual time=....
>>> rows=20 loops=1)
>>> Sort Method: top-N heapsort
>
>> Going off on a tangent, when I was playing with a merge-sort
>> implementation I propagated limit information into the sort
>> node, for a significant win.
>
> I'm not entirely following. The top-N heapsort approach already
> makes use of the limit info.
Having gone back to look, you're right. It was Uniq nodes I merged
(the sort handles both bounded-output and dedup).
--
Cheers,
Jeremy
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-11-14 20:36:53 | Re: New storage parameter pages_per_range not mentioned in CREATE INDEX doc |
Previous Message | Jim Nasby | 2014-11-14 20:02:38 | Re: TODO request: log_long_transaction |