[postgis-devel] automatic BVOL on spatial columns

[Paul Ramsey]

What won't be quick? The code or the implementation of the code?
P

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
> 
>