[postgis-devel] Alignment Revision

strk strk at keybit.net
Wed Jan 21 02:53:31 PST 2009


On Wed, Jan 21, 2009 at 10:38:03AM +0000, Mark Cave-Ayland wrote:

> In order to get the LWGEOM in/out of PostgreSQL we need to 
> serialize/deserialize the geometry. So what we are handed by PostgreSQL 
> is actually a *SERIALIZED* LWGEOM and so we must deserialize it into a 
> LWGEOM structure that we can actually do something useful with.

Correct. We deserialize for covenience, but do not copy actual vertex
data (doubles).

> The most 
> interesting part about this is that during the opposite process of 
> serialization, we have to iterate through any point arrays within a 
> LWGEOM anyway in order to memcpy() them into serialized form ready to 
> return to PostgreSQL.

We don't memcpy each value here (at least we do not need to) but
rather memcpy the whole pointarray data. No copying is required
if the function implements a read-only operation.

> Copying the minimal amount of information from the head of a serialized 
> LWGEOM to a LWGEOM will be extremely quick, and so I'm not worried about 
> this. Therefore the key is to make the coordinate arrays double-aligned 
> within the PostgreSQL Datum so that during the deserialization process, 
> we can just point the POINTARRAY straight into the Datum - which is what 
> already happens.

To rephrase, the key is to make the on-disk coordinate arrays
double-aligned so that during inspection we can just cast every
ordinate pointer to a double w/out incurring in either a performance
penalty (x86) or misread (on architectures that do not allow reading
a double from a non-double aligned memory address).
Correct ?

> Hence all we have to do is:
> 
> 	- Ensure the double arrays are aligned within the Datum
> 	- Rewrite any accessor methods to iterate through the
> 	array pointer directly, rather than through
> 	getPoint_internal

You mean ratehr then through getPoint_p here, as getPoint_internal
is what returns a pointer into the POINTARRAY, which can be or not
aligned depending on where the POINTARRAY comes from.
If you allocated the POINTARRAY yourself it will be aligned, if
it cams from the PostgreSQL Datum, it may or not be depending
on how it was written.

This is an interesting thread as I proceed defining memory structures
to use for holding rasters as in that case we'll have different
alignment constraints based on pixeltype (from 1 to 8 bytes per byte,
so requiring different padding).

--strk;



More information about the postgis-devel mailing list