[postgis-users] JTS -- was Re: Transform Performance

Robert Burgholzer rburghol at chesapeakebay.net
Wed Oct 26 14:46:42 PDT 2005


With regard to general performance, are the performance hits due to
execution of java functions?

I ask because, I think I found that the intersection() function seems to
be java based (in JTS). Is this a correct interpretation of what is
going on? I suppose I could just RTFLA (the friendly list archives that
is), as I recall the topics of porting java functions to postgis. I had
understood that this was the porting of java to C++, but perhaps that is
untrue. Anyone that can clarify this?

r.b.


On Wed, 2005-10-26 at 16:17, Charlie Savage wrote:
> Very interesting.  Following your lead I created this function and then 
> ran it through the scenarios you discuss below.
> 
> CREATE OR REPLACE FUNCTION
> testme(value int) RETURNS int
> AS $$
> BEGIN
> 	RAISE INFO 'testme: %', value;
> 	RETURN value;
> END;
> $$
> LANGUAGE plpgsql IMMUTABLE;
> 
> 
> I thought, but was wrong, that in this case the function would only be 
> called once:
> 
> select testme(MyField) from MyTable;
> 
> I had hoped that Postgresql would cache the value of the input 
> parameter, see that testme had already been invoked for that parameter, 
> and skip the evaluation.  However, it does not, the method get called 
> for every record.  From the Postgresql docs (emphasis is mine):
> 
> "An IMMUTABLE function cannot modify the database and is guaranteed to 
> return the same results given the same arguments forever. This category 
> allows the optimizer to pre-evaluate the function when a query calls it 
> with *constant* arguments."
> 
> > 
> > POSSIBLE OPTIMIZATIONS
> > 
> > First optimization that comes to mind is reducing scans by making
> > outer-level get_proj4_from_srid() calls take a constant argument:
> > 
> > 	transform_geometry(g, get_proj4_from_srid(find_srid(..)),
> > 		get_proj4_from_srid(4326));
> > 
> 
> Perhaps a quick simple way to do this is to create an overloaded version 
> of transform that takes both the source srs and targer srs as constants. 
>   That would get rid of all the SRID calls, and all but two of the 
> get_proj4_from_srid calls.  Thus it would be a lot faster, but not much 
> harder to use.
> 
> Thanks,
> 
> Charlie
> 
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
-- 
Non-point Source Data Analyst
University of Maryland, College Park
Chesapeake Bay Program Office
410 Severn Avenue, Suite 305B
Annapolis, MD, 21403
Phone: (410) 267-5779

rburghol at chesapeakebay.net




More information about the postgis-users mailing list