Gregory Stark <stark@enterprisedb.com> writes:
> I've been looking at doing the following TODO item:
> Allow ORDER BY ... LIMIT # to select high/low value without sort or index
> using a sequential scan for highest/lowest values

> I think this is pretty important to cover at some point because really _not_
> doing this just wrong.

I can't get all *that* excited about it, since an index solves the
problem.

> The way I see to do this is to still use a Sort node and use a tuplesort but
> to arrange to get the information of the maximum number of tuples needed to
> the tuplesort so it can throw out tuples as it sorts.

The implementation that was proposed in the earlier discussion did not
involve hacking the sort code beyond recognition ;-).

I believe a better way to think about this would be as an aggregate that
remembers the top N rows. It can't quite be an aggregate as it stands
(unless we want to invent aggregates that can return SETOF?) but I
think there might be some useful overlap with the SQL2003
window-function concept.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster