Mamta Satoor wrote:
Excuse my ignorance, but what does it mean by "order by that spills to
the disk"?
My interpretation of this is that when derby executes a statement with
an order by it has to somehow sort the rows. Derby has 2 methods of
doing this:
1) Carefully craft the execution plan to take advantage of an existing
index that exactly matches the order by.
2) Throw all the result rows into the sorter.
In case 2 there are basically 2 paths through the code:
1) if we have enough memory we sort all the rows in memory.
2) if we don't have enough memory we "spill to disk", basically we use
a disk based sort algorithm. This code is different from the btree
index code.
Mamta
On 3/15/07, *Mike Matrigali* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>> Daniel John Debrunner wrote:
>>
>>> ...
>>>
>>> - The collation type (the integer) is written into the
meta-data for
>>> an index just as ascending/descending is today (including the btree
>>> control row, thus making the information available for recovery).
>>> Collation type applies to all character columns in the index.
>>>
>> This suggests that all of the columns in the index must have the
same
>> collation? I don't think that is powerful enough to support the
>> full-blown SQL collation language, which allows you to mix
differently
>> collated columns in an ORDER BY clause. Why can't the collation
type
>> be an array of ints just as the sort direction is an array of
booleans
>> in IndexDescriptor?
>
>
> That would be more flexible, but is it required? Is an order by that
> spills to disk implemented using a BTREE?
No, order by that spills to disk is implemented by the sorter.
>
> Thanks,
> Dan.
>
>
>
