Re: Cube extension improvement, GSoC

Hi Stas, and sorry for the late response.

On 23.03.2013 01:10, Stas Kelvich wrote:
>    * Adding point data type support to the cube extension in order to avoid storing of coincident upper left and
lowerright vertices, which may reduce the volume that leaf nodes occupy almost twice.
 

Makes sense. I think it would be possible to implement this as an 
optimization to existing cube data type, so that a cube that is actually 
a point is simply stored more efficiently. Ie. set a flag in the NDBOX 
struct indicating that the cube is a point, and omit the second set of 
coordinates if that's set.

>    * Learning cube extension to store dimensions with different data types. Such index would be good alternative to
compoundkey B-Tree multi-index (suitable for diapason queries and data ordering).
 

You mean, a cube containing something else than floats? I don't think we 
want to explode the number of datatypes by doing that, casting between 
them could be problematic. But I wonder if you could add cube-like 
operators for arrays. We already have support for arrays of any 
datatype, and any number of dimensions. That seems awfully lot like what 
the cube extension does.

- Heikki