From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize ORDER BY ... LIMIT |
Date: | 2006-09-15 19:12:46 |
Message-ID: | 87irjposep.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I believe a better way to think about this would be as an aggregate that
> remembers the top N rows.
Wouldn't such a thing just be a reimplementation of a tuplestore though? I
mean, it's storing tuples you feed it, sorting them, and spitting them back
out in sorted order.
What would you do if the set of tuples turned out to be larger than you
expected and not fit in memory? Create a tuplesort and pass them on to it?
I've already looked at tuplesort and the changes there are minimal. The hard
part is what to do in the planner and executor to get the information to the
tuplestore. Do we want the plan to look the way it does now or use some new
sort of node that consolidates the limit and the sort in the same place.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-09-15 19:21:51 | Re: Optimize ORDER BY ... LIMIT |
Previous Message | Martijn van Oosterhout | 2006-09-15 19:02:32 | Re: Reducing data type space usage |