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 lower right 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 compound key 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
