[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