<html>
<head>
</head>
<body>great<br />
<br />
.. or not so great, would have been more way that way I guess ...<br />
<br />
<br />
<br />
2011-01-05 skrev Paul Ramsey :<br />
<br />
Yes, sure. And now that I've counted the tree traversal that makes me<br />
>even more sure.<br />
><br />
>P<br />
><br />
>On Wed, Jan 5, 2011 at 7:33 AM, Nicklas Avén
<nicklas.aven@jordogskog.no> wrote:<br />
>> Hi Paul<br />
>><br />
>> Sorry for repeating myself, but are you sure you don't have a 3d index after<br />
>> all, even if you input 2d geometries. From some<br />
>> "add-empty-z-value-mechanism"?<br />
>><br />
>> just curious<br />
>><br />
>> /Nicklas<br />
>><br />
>> 2011-01-05 skrev Paul Ramsey :<br />
>><br />
>> And I just did turn on logging and hey presto, both indexes take about<br />
>>>the same number of tree traversals to generate the result. So the<br />
>>>trees are more-or-less the same shape. So... what's left? I'll post<br />
>>>the shark results to see if anything jumps out at you Mark, doesn't<br />
>>>jump out at me. At this point the only thing I've got left is using a<br />
>>>varlena key in the new index and a fixed length one in the old one.<br />
>>><br />
>>>P.<br />
>>><br />
>>>On Fri, Dec 31, 2010 at 3:15 PM, Paul Ramsey wrote:<br />
>>>> Actually first I need to just turn on logging and count the number of<br />
>>>> calls to gist consistent. If my guess about the bad tree is right, I should<br />
>>>> see about five times as many calls on the new index. If the number of calls<br />
>>>> is in the same order of magnitude, suspicion shifts to the varlena key and<br />
>>>> associated overhead (which I find hard to believe).<br />
>>>><br />
>>>> I have already run it through the shark and it is not very useful... At<br />
>>>> least the functions it points to don't scream, hey! Look at my huge<br />
>>>> overhead!<br />
>>>><br />
>>>> P.<br />
>>>><br />
>>>> On 2010-12-31, at 4:11 AM, Mark Cave-Ayland wrote:<br />
>>>><br />
>>>>> On 31/12/10 06:15, Paul Ramsey wrote:<br />
>>>>><br />
>>>>>> Actually, testing again on the laptop (apples to apples) the speed<br />
>>>>>> different with 2D data is down to 3ms-on-new vs 1ms-on-old. When<br />
>>>>>> pulling a much larger result set (2000 records) the speed difference<br />
>>>>>> is 10ms-on-new vs 6ms-on-old. So it's closer, but still not<br />
>>>>>> equivalent.<br />
>>>>>><br />
>>>>>> P.<br />
>>>>><br />
>>>>> Sounds like it's time to build a profileable version of the library. Can<br />
>>>>> you build with CFLAGS="-O0 -pg" and then use your favourite profiling tool<br />
>>>>> (gprof/Shark) to see the differences in where the time is being spent?<br />
>>>>><br />
>>>>><br />
>>>>> ATB,<br />
>>>>><br />
>>>>> Mark.<br />
>>>>><br />
>>>>> --<br />
>>>>> Mark Cave-Ayland - Senior Technical Architect<br />
>>>>> PostgreSQL - PostGIS<br />
>>>>> Sirius Corporation plc - control through freedom<br />
>>>>> http://www.siriusit.co.uk<br />
>>>>> t: +44 870 608 0063<br />
>>>>><br />
>>>>> Sirius Labs: http://www.siriusit.co.uk/labs<br />
>>>>> _______________________________________________<br />
>>>>> postgis-devel mailing list<br />
>>>>> postgis-devel@postgis.refractions.net<br />
>>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<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 />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<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 />
>
</nicklas.aven@jordogskog.no>
</body>
</html>