<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Mark Cave-Ayland wrote:
<blockquote cite="mid:1200679004.22468.7.camel@mca-desktop" type="cite">
<pre wrap="">On Fri, 2008-01-18 at 09:26 -0800, Ben Jubb wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Hi Mark,<br>
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. <br>
<br>
doing some profiling on this code is my next task..<br>
<br>
b<br>
</body>
</html>