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