Re: Planning aggregates which require sorted or distinct

On Sat, 2007-01-20 at 13:36 +0000, Gregory Stark wrote:
> "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:
>
> > Simon Riggs wrote:
> >
> >> I'm working on modifying Tuplestore that will allow you to store the
> >> last N tuples, rather than all previous input. This is specifically
> >> designed to allow Merge Join to do Mark/Restore without materializing
> >> the whole sort set. This can also be used to materialize Windows (i.e.
> >> <window clause> in SQL:2003), so you can store the current row plus n
> >> PRECEDING and/or n FOLLOWING rows as appropriate.
> >
> > Interesting. This could also be used to implement the "partial sort"
> > stuff that Oleg is so interested in, and in which I believe Greg Stark
> > was also interested.
>
> I already have that implemented in tuplesort. The place where I was asking for
> more guidance was at higher levels. How to communicate this information down
> to the Sort node.
>
> It's not exactly the same as this case where you want to control when the old
> tuples are purged though. I think the SORT LIMIT case is simpler since it you
> just have to tell the tuplesort how many tuples you're interested in and it
> can take care of pruning irrelevant tuples as it goes.

It does sound the same, but I think Greg is right: Sort Limit optimises
the sort itself, not how the processing is handled following the Sort.
Both approaches are required, for different cases.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com