org.apache.derby.impl.sql.execute
Class SortResultSet

java.lang.Object
  extended by org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl
      extended by org.apache.derby.impl.sql.execute.NoPutResultSetImpl
          extended by org.apache.derby.impl.sql.execute.SortResultSet
All Implemented Interfaces:
CursorResultSet, NoPutResultSet, ResultSet, RowLocationRetRowSource, RowSource

 class SortResultSet
extends NoPutResultSetImpl
implements CursorResultSet

Takes a source result set, sends it to the sorter, and returns the results. If distinct is true, removes all but one copy of duplicate rows using DistinctAggregator, which really doesn't aggregate anything at all -- the sorter assumes that the presence of an aggregator means that it should return a single row for each set with identical ordering columns.

If aggregate is true, then it feeds any number of aggregates to the sorter. Each aggregate is an instance of GenericAggregator which knows which Aggregator to call to perform the aggregation.

Brief background on the sorter and aggregates: the sorter has some rudimentary knowledge about aggregates. If it is passed aggregates, it will eliminate duplicates on the ordering columns. In the process it will call the aggregator on each row that is discarded.

Note that a DISTINCT on the SELECT list and an aggregate cannot be processed by the same SortResultSet(), if there are both aggregates (distinct or otherwise) and a DISTINCT on the select list, then 2 separate SortResultSets are required (the DISTINCT is a sort on the output of the sort with the aggregation).

Currently, all rows are fed through the sorter. This is true even if there is no sorting needed. In this case we feed every row in and just pull every row out (this is an obvious area for a performance improvement). We'll need to know if the rows are sorted before we can make any optimizations in this area.

CLONING: Cloning and sorts are an important topic. Currently we do a lot of cloning. We clone the following: