[postgis-users] topology performance improvement purpose

[Sandro Santilli]

On Thu, May 03, 2012 at 12:13:58AM +0200, Jose Carlos Martinez Llario wrote:
> i meant not the default schema in search_path but the first topology
> working schema after public.

In order for your idea to work reliably the topology schema
must really be the first one, even before public. Or existance
of an "edge" or "node" or "relation" or "face" or "edge_data"
relation in public would break the functions.

It's surely an interesting idea worth trying out.

I've been thinking that we'd also want "internal"
functions for use by other "external" ones, for the same
performance reason (for example to reduce checks when 
the caller knows it already performed them).

There could be such "internal" functions taking no topology
name but rather assuming the topology schema is the first
in search_path. But even changing single functions to do
the search_path trick only internally might show up improvements.

The testsuite for topology is pretty robust so any implementation
should be easy to check for regressions. Of course there's no test
for the presence of specially named tables in the public schema
which we should add to prevent regressions like the above.

Do you feel like producing performance tests ? Such tests should
generate common cases of expensive datasets and run the functions
over them, reporting timings of each run. Won't be easy to test
"hot" runs with mutating functions...

Addressing each specific function in turn would likely help
managing this process. Maybe starting from one that's known to
hit often.

--strk;

> 
> On 02/05/2012 23:58, Jose Carlos Martinez Llario wrote:
> >Hi,
> >wanted to share a though about improving the topology performance
> >in postgis.
> >
> >Many of the functions are using EXECUTE instead of running
> >directly select commands.
> >In many cases this is need just because of the used of the schema
> >name  of the topology primitive tables.
> >
> >I found between 4 and 10 times improving performance some
> >sentences. I guessing it could be even better.
> >
> >My question is if an approach like the following makes sense:
> >
> >1.- With one command we can make the current topology schema the
> >default schema in search path,
> >2.- then working with topology
> >3.- Change search_path again when finishing the spatial analysis.
> >
> >(the parameter of the topology name in the functions should be
> >ignored or removed)
> >I know it requires a lot of changes but currently the performance
> >of the persistent topology is too slow.
> >
> >if one do that many functions can be run without EXECUTE. Spatial
> >analysis between different topologies is not possible which fits
> >the procedure.
> >
> >What do you think Sandro?
> >
> >Regards,
> >Jose
> >
> >_______________________________________________
> >postgis-users mailing list
> >postgis-users at postgis.refractions.net
> >http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

-- 

  ,------o-. 
  |   __/  |    Delivering high quality PostGIS 2.0 !
  |  / 2.0 |    http://strk.keybit.net - http://vizzuality.com
  `-o------'