<html>
<head>
</head>
<body>Paul<br />
        <br />
        yes, it seemed like a great theory. are you sure it is not building a 3d index anyway. <br />
        can you confirm that the "DIMENSIONALITY<br />
         
DETERMINED BY THE DATA" thing is working. Is there no mechanism somewhere that adds an empty z coordinate like get_3d_point (or whatever  the name is) is doing.<br />
        <br />
        /Nicklas<br />
        <br />
        <br />
         2010-12-31 skrev Paul Ramsey :<br />
        <br />
        Well, it was a great theory, but my test did not bear it out. Even<br />
        
>with 2D inputs the new index is still taking about 5x longer to return<br />
        
>a small result set as the old one. :(<br />
        
><br />
        
>P<br />
        
><br />
        
>On Thu, Dec 30, 2010 at 3:32 PM, Paul Ramsey 
        <pramsey@opengeo.org> wrote:<br />
                
>> You edit the postgis/gserialized.h file and define or undef GSERIALIZED_ON<br />
                
>><br />
                
>> BTW, I have a theory now which I just need to test... the data are 3D!<br />
                
>> And in fact the new GiST index will build an index WITH DIMENSIONALITY<br />
                
>> DETERMINED BY THE DATA. Not by the opclass. So the tree built with the<br />
                
>> new index is going to be more expensive to search in 2D than an actual<br />
                
>> 2D tree would have been. I just need to change my input data to 2D and<br />
                
>> see if the performances fall into line to confirm my guess.<br />
                
>><br />
                
>> P.<br />
                
>><br />
                
>> On Thu, Dec 30, 2010 at 12:50 AM, Andrea Peri 
                <aperi2007@gmail.com> wrote:<br />
                        
>>><br />
                        
>>>>On my lap top the loading and index building take about the same<br />
                        
>>>>amount of time, but the query runs in about 1ms for the old index and<br />
                        
>>>>about 5ms for the new one. My assumption (thus unconfirmed) is that<br />
                        
>>><br />
                        
>>>>the problem is not in the consistent checks (doing things like<br />
                        
>>>>reducing the size of the slice detoasted to the minimum necessary for<br />
                        
>>>>2d queries only improved the times by about 10%) but rather in the<br />
                        
>>><br />
                        
>>>>tree itself: that the new index is just building a crappier tree, so<br />
                        
>>>>the query has to traverse more of it to get the same answer.<br />
                        
>>><br />
                        
>>> There even an increase of memory resource needed ?<br />
                        
>>><br />
                        
>>> To test this version there is a new key setting to apply in the .configure,<br />
                        
>>><br />
                        
>>> or need to change manually the definitions ?<br />
                        
>>><br />
                        
>>> --<br />
                        
>>> -----------------<br />
                        
>>> Andrea Peri<br />
                        
>>> . . . . . . . . .<br />
                        
>>> qwerty אטלעש<br />
                        
>>> -----------------<br />
                        
>>><br />
                        
>>><br />
                        
>>> _______________________________________________<br />
                        
>>> postgis-devel mailing list<br />
                        
>>> postgis-devel@postgis.refractions.net<br />
                        
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
                        
>>><br />
                        
>>><br />
                        
>><br />
                        
>_______________________________________________<br />
                        
>postgis-devel mailing list<br />
                        
>postgis-devel@postgis.refractions.net<br />
                        
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
                        
><br />
                        
>
</aperi2007@gmail.com></pramsey@opengeo.org>
</body>
</html>