From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Stas Kelvich <stanconn(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cube extension improvement, GSoC |
Date: | 2013-05-04 17:56:44 |
Message-ID: | CAPpHfduvs=KAY=zRVUw4Q3bAh_J_+ZeUe_o57xK4vo08jwGcNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 2, 2013 at 4:19 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com>wrote:
> * 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.
At least option for having float4 cube instead of foat8 cube seems
reasonable for me, because of space economy payed by less accuracy.
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.
I think we have at least 3 data types more or less similar to cube.
1) array of ranges
2) range of arrays
3) 2d arrays
Semantically cube is most close to array or ranges. However array of ranges
have huge storage overhead.
Also we can declare cube as domain on 2d arrays and declare operations of
that domain.
------
With best regards,
Alexander Korotkov.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2013-05-04 17:59:40 | Re: 9.3 release notes suggestions |
Previous Message | Tomas Vondra | 2013-05-04 17:50:50 | Re: 9.3 release notes suggestions |