[postgis-devel] automatic BVOL on spatial columns

[strk at refractions.net]

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.

Comments ?

--strk;

On Thu, Dec 30, 2004 at 02:02:02PM +0100, strk at refractions.net wrote:
> On Wed, Dec 29, 2004 at 04:00:04PM -0800, Paul Ramsey wrote:
> > If your only/main worry is that we are taking away configurability from 
> > the user, then you should cease worrying. Too much configurability can 
> > be a *bad* thing, in the hands of people who do not want to have it. It 
> > forces them to make a bunch of decisions about things that they really 
> > do not want to know about, right away when they are still trying to 
> > learn basic things about the software.
> > 
> > What we want is a default configuration that "works pretty good", and 
> > without *any* special knowledge or configuration on the part of the user 
> > about abstract things like bbox caching strategies and their consequences.
> > 
> > If we make configurable caching a compile-time option or "special fiddly 
> > runtime" option, we can document how to use it, and the 1% of users who 
> > want to wring every last drop of performance out of their installations 
> > can read it and figure how to use it.
> > 
> > The rest will not know, will not care, and will live longer happier lives.
> > 
> > Paul
> 
> Ok. Point taken.
> 
> I'll go through the process of enforcing bbox caching based
> on some heuristic. What I can think of is a function taking
> care of applying the hauristic to PG_LWGEOM and LWGEOM objects.
> Here is a question: should a geometry for which cache conditions
> are not met loose an eventually already present bbox ?
> 
> --strk;
> 
> > 
> > strk at refractions.net wrote:
> > >>Also, this logic should be left to the user, so she can decide when to
> > >>cache and when not to. She might want fast load and successive
> > >>bbox caching, she might want to cache bbox only on indexed tables,
> > >>or only for geoms with npoints > X in a table and > Y in another.
> > >>
> > >>I just don't see an easy way though :(
> > 
> > _______________________________________________
> > 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/