[postgis-devel] What's the difference between geom_accum andbuiltin postgresql array_append

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Tue Sep 2 15:23:43 PDT 2008


Obe, Regina wrote:
> 
> Getting back to this topic.  Recall I said there was a situation where 
> LWGEOM_accum worked where array_append didn't.  I can't replicate it so 
> I suspect it was an earlier error in my indexing efforts that caused 
> this issue.  I am also not seeing this LWGEOM_accum function used 
> directly in any of the postgis code base.
> 
> So here is my half-assed suggestion since no one seems to know why we 
> should maintain the LWGEOM_accum function instead of just using built-in 
> PostgreSQL array_append function.
> 
> Simply get rid of LWGEOM_accum from our code base (or deprecate it) -- 
> change
> 
> /**CREATE OR REPLACE FUNCTION st_geom_accum(geometry[], geometry)
>   RETURNS geometry[] AS
> '$libdir/liblwgeom.dll', 'LWGEOM_accum'
>   LANGUAGE 'c' IMMUTABLE;
> ***/
> 
> To:
> CREATE OR REPLACE FUNCTION st_geom_accum(geometry[], geometry)
>   RETURNS geometry[] AS
> $$ SELECT array_append($1,$2);  $$
>   LANGUAGE 'sql' IMMUTABLE;
> 
> 
> And that's it.  In tests I've done doing above, I don't see a definitive 
> speed difference and all aggs we have seem to have this function for 
> collecting geometries. 
> 
> I would have suggested replacing our use in aggregates directly with 
> array_append, but thought it would be better to keep this buffer for 3 
> reasons
> 1) We don't have a CREATE OR REPLACE AGGREGATE which makes changing aggs 
> without a drop reload tricky. Changing this function will auto-magically 
> correct the aggs. Granted 1.4 people should be doing a full reload anyway.
> 
> 2) Don't know if anyone is relying on the st_geom_accum function so we 
> probably should keep it around anyway.
> 
> 3) In case we are wrong.  It won't be a major undertaking to correct the 
> mistake.
> 
> Any thoughts, concerns?
> 
> Thanks,
> Regina


Hi Regina,

At a quick glance, I'd say that the LWGEOM_accum function forcibly 
de-TOASTs the input geometries when building the array so it may be that 
you will only see a time difference working very large geometries 
(rather than large numbers of smaller geometries). Does this make any 
difference in your tests?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063



More information about the postgis-devel mailing list