[postgis-devel] automatic BVOL on spatial columns

[strk at refractions.net]

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/