[postgis-devel] Updates to GEOS & POSTGIS

Ben Jubb benjubb at refractions.net
Fri Jan 18 10:15:47 PST 2008



Mark Cave-Ayland wrote:
> On Fri, 2008-01-18 at 09:26 -0800, Ben Jubb wrote:
>
>   
>> Mark,
>> thanks for the comments,
>>
>> - I'll change the comment style.. 
>>
>> - added the initGEOS() calls, oops..
>>
>> - the size calculation: ill try your suggestion for getting
>> arg1_length.
>>
>> The method I use to check the identity of the first geometry argument
>> is troublesome to me.  Right now, I do a memcmp() on the de-toasted
>> argument, and the previously stored argument in the cache.  This seems
>> like alot of work to me, but I having trouble coming up with a better
>> way.  One way that occured to me is to store the toasted data in the
>> cache instead, and do the comparison on the compressed data instead.
>> But is there a future-proof way to get the uncompressed data for the
>> datum?  Looks like I need to rip out the guts of toast_fetch_datum()
>> to do it.
>>
>> cheers
>> b
>>     
>
>
> Hi Ben,
>
> Unfortunately toasted data isn't just compressed - it can represent data
> which is held "out of line" of the table in a separate table. You can
> see these by looking for table names beginning pg_toast in the catalogs.
> So for this reason I don't think you can do what you were hoping :(
>
> Can you confirm using gprof or similar tools that the detoasting is
> where the time is being spent? If so, we can have a think about how to
> optimise it...
>
>
> ATB,
>
> Mark.
>
>   
Hi Mark,
I realize the data isnt necessarily compressed when its toasted, and 
that its possibly stored in a seperate table.  What I was hoping was 
that I could get a buffer with the raw data (compressed or not) after 
its been re-constituted, and use that at the identity key for the 
geometry object.  Im not so concerned about the de-toasting performance, 
as I am about the necessity of doing a bit-wise comparison on a large 
memory blob everytime through the function.   Seems to me that keeping 
the size of that blob as small as possible is a good idea. 

doing some profiling on this code is my next task..

b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080118/08cad234/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: benjubb.vcf
Type: text/x-vcard
Size: 255 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080118/08cad234/attachment.vcf>


More information about the postgis-devel mailing list