<!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>