Re: EXPLAIN ANALYZE output weird for Top-N Sort

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

In response to

Responses

Browse pgsql-hackers by date

  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