From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeremy Harris <jgh(at)wizmail(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EXPLAIN ANALYZE output weird for Top-N Sort |
Date: | 2014-11-14 14:54:39 |
Message-ID: | 22880.1415976879@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
If the limit is so large that the sort spills to disk, then we
stop thinking about the limit. But I'm finding it doubtful either
that that's a case worthy of extra code or that you could get very
much win if you did add code for it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-11-14 15:02:08 | Re: REINDEX CONCURRENTLY 2.0 |
Previous Message | Alvaro Herrera | 2014-11-14 14:37:11 | Re: Teaching pg_dump to use NOT VALID constraints |