[postgis-devel] automatic BVOL on spatial columns

[strk at refractions.net]

I've added in the repository a report of all functions returning
a geometry. For each function the bbox cache strategy is documented
and also the output construction mean. We have different means of 
output construction:

	Custom (the functions internally create the output geom)
	Serialized (the function use PG_LWGEOM_construct)
		- this is always applicable to Custom as it   -
	        - takes an already serialized object in input -
	LWGEOM (the cleanest and easier way)

I've enforced a single entry point for LWGEOM construction, so
every function using the LWGEOM way will have a single entry
point for output creation. This won't help for strategies NOT
based on output geometry.

Please take a look at the document (BBOXCACHE_BEHAVIOURS).
More later (or next year).

--strk;

On Fri, Dec 31, 2004 at 09:41:11AM +0100, strk at refractions.net wrote:
> On Thu, Dec 30, 2004 at 01:28:03PM -0800, Paul Ramsey wrote:
> > 
> > What won't be quick? The code or the implementation of the code?
> > P
> 
> I was referring to the implementation (serializers are
> recursive function, so *every* function needs to take
> the caching strategy into consideration somehow (or
> all serializers will need another argument stating wheter
> or not it is a top-level geometry or not).
> 
> The code will be slower whenever the box is computed for
> intermediate geometries even if not needed.
> 
> For example:
> 
> 	SELECT summary(buffer(convexhull(
> 		simplify(<polygon>, 1)), 1));
> 
> That query would compute bbox for the <polygon>, for the
> simplified polygon, for the convexhull, and for the buffered
> geom (4 times), when at the end the cache won't be used
> at all.
> 
> --strk;
> 
> > 
> > strk at refractions.net wrote:
> > 
> > >On Thu, Dec 30, 2004 at 10:00:21AM -0800, Paul Ramsey wrote:
> > >
> > >>Sounds good and simple to me, good stuff!
> > >>
> > >>P
> > >
> > >
> > >Good. I'll take that path then.
> > >Note that it won't be a quick operation (see report on the
> > >various functions and their bbox cache behaviour.
> > >
> > >--strk;
> > >
> > >
> > >>strk at refractions.net wrote:
> > >>
> > >>
> > >>>I've made canonical, (E)WKT and (E)WKB and GEOS input methods
> > >>>call a function returning wheter it's worth to cache bbox, and
> > >>>add it accordingly. None of this methods will face the problem
> > >>>of wheter to drop an existing cache, as transport formats do
> > >>>not contain that information. GEOS Geometry could potentially
> > >>>store an Envelope, but that's not automatically converted by
> > >>>the existing converters.
> > >>>
> > >>>Note that many geometry editors decide wheter or not to
> > >>>add a bbox cache to their return based on other heuristics.
> > >>>Some of them add a bbox if its input geom does have a cache
> > >>>already ( transform, translate, reverse, simplify, segmentize ),
> > >>>some always avoid a bbox computation ( collect, addpoint ).
> > >>>
> > >>>To make this behaviour consistent every function returning
> > >>>a geometry should call the heuristic functions and explicitly
> > >>>cache a bbox when the conditions match. 
> > >>>
> > >>>Still I'm convinced that the user should have more control
> > >>>over this aspect, more specifically she should decide when
> > >>>exactly to compute it in a chain of calls, to improve performace.
> > >>>Users willing to have this finer control can set AUTOCACHE_BBOX
> > >>>to 0 in Makefile.config. In this case internal functions should
> > >>>compute a bbox only if that is a simple operation (ie: does not
> > >>>require a scan of the geometry points). The implemented trigger
> > >>>would be then useful to ensure that tables used for frequent
> > >>>selects always have a bbox cached.
> > >>>
> > >>
> > >>
> > >>_______________________________________________
> > >>postgis-devel mailing list
> > >>postgis-devel at postgis.refractions.net
> > >>http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > >
> > >
> 
> -- 
> 
> For standing up against patentability of software,
> 
>   Thank You, Poland!
> 
> Read the intervention:    http://kwiki.ffii.org/ConsPolon041221En
> Send your thanks:         thankyoupoland.info
> Read/do more:		  http://www.noepatents.org/
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

-- 

For standing up against patentability of software,

  Thank You, Poland!

Read the intervention:    http://kwiki.ffii.org/ConsPolon041221En
Send your thanks:         thankyoupoland.info
Read/do more:		  http://www.noepatents.org/