Re: [HACKERS] Cube extension improvement, GSoC

2013-05-14 Thread Stas Kelvich
HI. Thanks, Heikki, for the answer on google-melange. For some reason i didn't receive email notification, so I saw this answer only today. Do you have access to a server you can use to perform those tests? (...) Yes, i have. I am maintaining MPI cluster in my university, so it is not a

Re: [HACKERS] Cube extension improvement, GSoC

2013-05-14 Thread Alexander Korotkov
On Tue, May 14, 2013 at 4:30 PM, Stas Kelvich stanc...@gmail.com wrote: * Don't do cube with type support Eventually, there is different ways of reducing R-Tree size. For example we can store relative coordinates with dynamic size of MBR (VRMBR), instead of absolute coordinates with

Re: [HACKERS] Cube extension improvement, GSoC

2013-05-14 Thread Stas Kelvich
On May 14, 2013, at 4:53 PM, Alexander Korotkov wrote: Sounds promising. Did you examine how this technique can fit into GiST? In current GiST interface methods don't have access to parent entries. No, i didn't examine it yet. Anyway in this technique lots of changes should be performed to

Re: [HACKERS] Cube extension improvement, GSoC

2013-05-08 Thread Alexander Korotkov
On Sat, May 4, 2013 at 11:19 PM, Stas Kelvich stanc...@gmail.com wrote: 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

Re: [HACKERS] Cube extension improvement, GSoC

2013-05-04 Thread Alexander Korotkov
On Thu, May 2, 2013 at 4:19 PM, Heikki Linnakangas hlinnakan...@vmware.comwrote: * 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

Re: [HACKERS] Cube extension improvement, GSoC

2013-05-04 Thread Stas Kelvich
Hello. * 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

Re: [HACKERS] Cube extension improvement, GSoC

2013-05-02 Thread Heikki Linnakangas
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

Re: [HACKERS] Cube extension improvement, GSoC

2013-03-30 Thread Alexander Korotkov
Hi, Jey! I remember I've started couple of threads related to cube extension: http://www.postgresql.org/message-id/4f30616d.3030...@gmail.com http://www.postgresql.org/message-id/4f3c16e9.90...@gmail.com Could you provide some feedback to GSoC proposal of Stas? On Sat, Mar 23, 2013 at 3:10 AM,

Re: [HACKERS] Cube extension improvement, GSoC

2013-03-30 Thread Alexander Korotkov
On Sat, Mar 30, 2013 at 3:55 PM, Alexander Korotkov aekorot...@gmail.comwrote: Hi, Jey! I remember I've started couple of threads related to cube extension: Oh, it's a typo. I remember you've started those threads. http://www.postgresql.org/message-id/4f30616d.3030...@gmail.com

[HACKERS] Cube extension improvement, GSoC

2013-03-22 Thread Stas Kelvich
Hello, some time ago I started working on the data search system (about 100-200M of records) with queries consisted of several diapason and equality conditions, e.g.: WHERE dim1 BETWEEN 128 AND 137 AND WHERE dim2 BETWEEN 4815 AND 162342 AND WHERE dim3 = 42 ORDER BY dim1 ASC There are