From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Gavin Sherry <swm(at)alcove(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Planning aggregates which require sorted or distinct |
Date: | 2007-01-20 13:36:32 |
Message-ID: | 8764b1hlb3.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2007-01-20 13:44:23 | Re: Planning aggregates which require sorted or distinct |
Previous Message | Gavin Sherry | 2007-01-20 13:19:26 | Re: Planning aggregates which require sorted or distinct |