Re: Optimizing "top queries" ...

On Wed, Dec 06, 2006 at 03:34:02PM +0000, Gregory Stark wrote:
> One thing to keep in mind though is that I also wanted to cover the case of
> Unique(Sort(...)) and Limit(Unique(Sort(...))) which can throw away duplicates
> earlier. Do we want three different plan nodes? Are there other cases like
> these that can benefit?

I would think that we really don't want more than one type of sort
node. What I think would be good is the setting of Unique and Limit as
options to the Sort node. Instead of peeking across nodes at execution
time, have the optimizer merge them.

For Unique, you arrange to have the sort algorithm, if two nodes are
equal, to throw one of the tuples.

For Limit, you can do it by having the tapes stop writing after the
given number of rows.

However, I think there's a difference between Unique across all
columns, or Unique as in DISTINCT ON(). The latter would be easier to
integrate.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.