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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers