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