Re: EXPLAIN ANALYZE output weird for Top-N Sort

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 11:06:47
Message-ID: 5465E247.3020108@wizmail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. Eliding the Limit node gave
a further slight win.

I wasn't convinced the use-case was common enough to justify
the replacement of quicksort (despite having consistently
fewer compares, the merge sort was slightly slower. I never
understood why) - but I never asked. Is there any appetite
for supporting alternate sort algorithms?
--
Cheers,
Jeremy

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-11-14 11:42:59 Re: using custom scan nodes to prototype parallel sequential scan
Previous Message Kouhei Kaigai 2014-11-14 11:02:28 Re: using custom scan nodes to prototype parallel sequential scan