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